Quantcast

msp430-gdbproxy loses connection with target

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

msp430-gdbproxy loses connection with target

Andrew McLaren
I've been struggling with an (almost) repeatable issue with gdpproxy losing
connection with the target msp.
 
After operating correctly for a period, gdbproxy will suddenly report
"error: msp430: Could not determine device state (18)" in response to an
MSP430_State() request by gdbproxy.
then following this a stream of
"error: msp430: No error (0)" in response to a sequence of
MSP430_Memory(READ) requests.
 
At this point I've only been able to get this working again by repowering
the FET and the target msp (actually the target msp looks like its enough,
but its typically powered via the FET).
 
>From this I'm guessing that something in the logic being debugged is
corrupting the target msp's JTAG interface in some way, which effectively
disrupts communication with the FET. Repowering the target msp resets all
the interfaces to a known state, which gets things back in line. However,
even if this is the case, I'm not having much luck isolating where this is
happening, and hoping someone can give me some ideas or pointers which may
help in isolating this.
 
When I said 'almost' above, often this seems to trigger in the same sequence
in the logic, but not always, so its not totally predictable. I've been
trying to 'binary chop' the logic from where it is known good to where it is
often bad, but the lack of predicatability is running me in circles. I've
also forced the code to link in a different order (theory being that if it
was a relative addressing rather than absolute addressing issue, the problem
would move), but its remained much the same (but of course the lack of
predicatability means I can't be certain!) Where it is occuring it should be
running logic that has all previously been exercised a number of times.
 
- Does my diagnosis sound right, or at least reasonable?
- From what I can glean, the target msp (a 439) has a dedicated JTAG
interface, and can't see that any of this is configurable, even
inadvertently. Am I missing something here, or is there some other way the
JTAG interface can be impacted?
- Any other ideas for what could cause this?
- Any ideas or techniques for isolating this sort of problem.
 
The setup is Eclipse talking to the target MSP (a 439) via msp430-gdbproxy
(version 0.7.1), and a TI USB FET.
 
Thanks for any thoughts.
 
Andrew

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

Eric Decker
is there some reason you are using msp430-gdbproxy rather than mspdebug?

msp430-gdbproxy has been deprecated for many years now.

current devlopment is occuring on mspdebug.

it is a superset of msp430-gdbproxy.



On Sat, Aug 24, 2013 at 6:16 PM, Andrew McLaren <[hidden email]>wrote:

> I've been struggling with an (almost) repeatable issue with gdpproxy losing
> connection with the target msp.
>
> After operating correctly for a period, gdbproxy will suddenly report
> "error: msp430: Could not determine device state (18)" in response to an
> MSP430_State() request by gdbproxy.
> then following this a stream of
> "error: msp430: No error (0)" in response to a sequence of
> MSP430_Memory(READ) requests.
>
> At this point I've only been able to get this working again by repowering
> the FET and the target msp (actually the target msp looks like its enough,
> but its typically powered via the FET).
>
> >From this I'm guessing that something in the logic being debugged is
> corrupting the target msp's JTAG interface in some way, which effectively
> disrupts communication with the FET. Repowering the target msp resets all
> the interfaces to a known state, which gets things back in line. However,
> even if this is the case, I'm not having much luck isolating where this is
> happening, and hoping someone can give me some ideas or pointers which may
> help in isolating this.
>
> When I said 'almost' above, often this seems to trigger in the same
> sequence
> in the logic, but not always, so its not totally predictable. I've been
> trying to 'binary chop' the logic from where it is known good to where it
> is
> often bad, but the lack of predicatability is running me in circles. I've
> also forced the code to link in a different order (theory being that if it
> was a relative addressing rather than absolute addressing issue, the
> problem
> would move), but its remained much the same (but of course the lack of
> predicatability means I can't be certain!) Where it is occuring it should
> be
> running logic that has all previously been exercised a number of times.
>
> - Does my diagnosis sound right, or at least reasonable?
> - From what I can glean, the target msp (a 439) has a dedicated JTAG
> interface, and can't see that any of this is configurable, even
> inadvertently. Am I missing something here, or is there some other way the
> JTAG interface can be impacted?
> - Any other ideas for what could cause this?
> - Any ideas or techniques for isolating this sort of problem.
>
> The setup is Eclipse talking to the target MSP (a 439) via msp430-gdbproxy
> (version 0.7.1), and a TI USB FET.
>
> Thanks for any thoughts.
>
> Andrew
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>

--
Eric B. Decker
Senior (over 50 :-) Researcher

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

Andrew McLaren
No reason at all except maybe laziness. I did have a play with mspdebug a
few years back, and from memory had some issues with the target processor I
was using. gdbproxy worked, so I've stayed with that ever since. There is
always enough work in the code itself, so if the environment works I just
tend to leave it alone. I wasn't aware there was any formal plans to
deprecate gdbproxy, but was aware of a lot of the development/support
discusssions around this.
 
I'm in the process of reinstalling mspdebug, so we'll see if that makes any
difference. I'll let you know!
 
Thanks - Andrew

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

Andrew McLaren
In reply to this post by Andrew McLaren
It would have been easy if the problem had been gdbproxy, but no such luck.
Now that mspdebug is running, I'm seeing exactly the same scenario here. The
messages are a tad different, but I think they are saying the same thing.
Everything works fine until mspdebug reports...
 
fet: FET returned error code 18 (Could not determine device state)
fet: polling failed
 
Once again, eveything appears hung outboard of mspdebug until the target msp
is repowered. If I simply try and restart mspdebug without doing this, it
will report;
 
TI3410 device is in boot config, setting active
ti3410: TI_OPEN_PORT failed: A device attached to the system is not
functioning
ti3410: failed to set up port
 
Any ideas?
 
Andrew

 
No reason at all except maybe laziness. I did have a play with mspdebug a
few years back, and from memory had some issues with the target processor I
was using. gdbproxy worked, so I've stayed with that ever since. There is
always enough work in the code itself, so if the environment works I just
tend to leave it alone. I wasn't aware there was any formal plans to
deprecate gdbproxy, but was aware of a lot of the development/support
discusssions around this.
 
I'm in the process of reinstalling mspdebug, so we'll see if that makes any
difference. I'll let you know!
 
Thanks - Andrew


------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

Daniel Beer-3
On Tue, Aug 27, 2013 at 10:40:45AM +1200, Andrew McLaren wrote:

> It would have been easy if the problem had been gdbproxy, but no such luck.
> Now that mspdebug is running, I'm seeing exactly the same scenario here. The
> messages are a tad different, but I think they are saying the same thing.
> Everything works fine until mspdebug reports...
>  
> fet: FET returned error code 18 (Could not determine device state)
> fet: polling failed
>  
> Once again, eveything appears hung outboard of mspdebug until the target msp
> is repowered. If I simply try and restart mspdebug without doing this, it
> will report;
>  
> TI3410 device is in boot config, setting active
> ti3410: TI_OPEN_PORT failed: A device attached to the system is not
> functioning
> ti3410: failed to set up port

This looks like some kind of hardware problem. Have you tried different
USB ports?

Is the board powered externally, or does it draw power from the FET?

Cheers,
Daniel

--
Daniel Beer <[hidden email]>    www.dlbeer.co.nz
IRC: inittab (Freenode)    PGP key: 2048D/160A553B

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

Andrew McLaren
>
> On Tue, Aug 27, 2013 at 10:40:45AM +1200, Andrew McLaren wrote:
> > It would have been easy if the problem had been gdbproxy,
> but no such
> > luck. Now that mspdebug is running, I'm seeing exactly the same
> > scenario here. The messages are a tad different, but I
> think they are
> > saying the same thing. Everything works fine until mspdebug
> reports...
> >  
> > fet: FET returned error code 18 (Could not determine device state)
> > fet: polling failed
> >  
> > Once again, eveything appears hung outboard of mspdebug until the
> > target msp is repowered. If I simply try and restart
> mspdebug without
> > doing this, it will report;
> >  
> > TI3410 device is in boot config, setting active
> > ti3410: TI_OPEN_PORT failed: A device attached to the system is not
> > functioning
> > ti3410: failed to set up port
>
> This looks like some kind of hardware problem. Have you tried
> different USB ports?
>
> Is the board powered externally, or does it draw power from the FET?
>
> Cheers,
> Daniel
>

I've been having a bit of a play to try and isolate it, but haven't come up
with anything conclusive (or really anthing at all).

To answer your questions
- the target board is powered by the FET
- I've tried switching USB ports, but no change.

I've also tried switching the target processor (another 439), but also no
change. The only harware I haven't yet swapped out is the FET itself, but
only have the single TI FET running. I do have an Olimex FET here, but
having a few issues at present installing the drivers for that, so that is
the next step.

The ONLY thing I have found so far that resets the problem is repowering the
target MSP, which leads me to think that is must be some context in that
that is somehow being corrupted. I'd also like to try a different MSP
variant, but none of the others I have here have the ROM space this needs
(just thinking, I do have one of the TI experimeter boards around, and that
has a fairly hefty MSP on it, so that could be worth a go).

So I have a couple of things to try. I'll keep you posted.

Andrew


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

Eric Decker
have you verified that the board is getting the voltage that you think it
should be?


On Mon, Sep 2, 2013 at 3:38 PM, Andrew McLaren <[hidden email]> wrote:

> >
> > On Tue, Aug 27, 2013 at 10:40:45AM +1200, Andrew McLaren wrote:
> > > It would have been easy if the problem had been gdbproxy,
> > but no such
> > > luck. Now that mspdebug is running, I'm seeing exactly the same
> > > scenario here. The messages are a tad different, but I
> > think they are
> > > saying the same thing. Everything works fine until mspdebug
> > reports...
> > >
> > > fet: FET returned error code 18 (Could not determine device state)
> > > fet: polling failed
> > >
> > > Once again, eveything appears hung outboard of mspdebug until the
> > > target msp is repowered. If I simply try and restart
> > mspdebug without
> > > doing this, it will report;
> > >
> > > TI3410 device is in boot config, setting active
> > > ti3410: TI_OPEN_PORT failed: A device attached to the system is not
> > > functioning
> > > ti3410: failed to set up port
> >
> > This looks like some kind of hardware problem. Have you tried
> > different USB ports?
> >
> > Is the board powered externally, or does it draw power from the FET?
> >
> > Cheers,
> > Daniel
> >
>
> I've been having a bit of a play to try and isolate it, but haven't come up
> with anything conclusive (or really anthing at all).
>
> To answer your questions
> - the target board is powered by the FET
> - I've tried switching USB ports, but no change.
>
> I've also tried switching the target processor (another 439), but also no
> change. The only harware I haven't yet swapped out is the FET itself, but
> only have the single TI FET running. I do have an Olimex FET here, but
> having a few issues at present installing the drivers for that, so that is
> the next step.
>
> The ONLY thing I have found so far that resets the problem is repowering
> the
> target MSP, which leads me to think that is must be some context in that
> that is somehow being corrupted. I'd also like to try a different MSP
> variant, but none of the others I have here have the ROM space this needs
> (just thinking, I do have one of the TI experimeter boards around, and that
> has a fairly hefty MSP on it, so that could be worth a go).
>
> So I have a couple of things to try. I'll keep you posted.
>
> Andrew
>
>

--
Eric B. Decker
Senior (over 50 :-) Researcher

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

Andrew McLaren
Just to close the loop on this, I think I have found the problem (or at
least what the 439 MSP doesn't like).
 
The logic maintains a reference timebase using the timer B module (this
simply ticks away in the background and maintains a reference counter). To
obtain a time reference at any time, the logic stops the timer block, reads
the TBR, and restarts the timer block. Nothing really fancy there.
 
It was a bit of luck, but the only other relatively large MSP I had
available was the 4618 on an experimenters board. This also has a USART, so
there were only minimal code changes needed between the 439 and the 4618
(the 4618 is a USART1 rather than a USART0, and that was pretty much it).
However, the 4618 timer logic failed - when the timer was restarted, the TBR
was cleared, whereas the 439 restarted (as expected) from where the TBR was
stopped. This lead me to have a good look at how the timer block was stopped
and restarted.
 
To stop and restart the timer, the whole TBCTL was being rewritten, along
the lines of;
TBCTL = TBSSEL_1 | ID_3 | MC_0, and
TBCTL = TBSSEL_1 | ID_3 | MC_2
 
This worked fine on the 439 (or at least appeared to work fine!). However
stopping the timer block this way appeared to clear the TBR on the 4618,
even though the TBCLR bit wasn't being set. To get this to work correctly on
the 4618, I modified this to just touch the mode control bits, along the
lines of;
TBCTL = TBCTL & ~MC0 & ~MC1
TBCTL = (TBCTL & ~MC0) | MC1
 
This resolved the timer issues with the 4618, which now ran the logic with
no problems. Moreover, the logic functioned without any of the loss of
connectivity with the JTAG seen with the 439. Just out of curiousity, I
rebuilt the logic for the 439 and ran that again, and it also worked 100%. I
could turn the JTAG connectivity issues on and off simply by how I was
touching the TBCTL register.
 
A bit more playing and looking at the full TBCTL before I modify it, the
only difference between two two is that in the first case TBIFG is being
cleared, whereas in the modified case this is being left at its set state.
As I'm not using TBIE or TBIFG, this doesn't affect me at all. While the
second TBCTL strategy is explicitly only touching what is required, so is
probably better, I can't see why the initial strategy should have caused any
issues (and also why it should have cleared the TBR on 4618, but luckily it
did!).
 
Its curiousity value now, but if anyone can give me any insights into why
this has happened, I'd like to know! Thanks for the help and pointers in
resolving this.
 
Andrew

-----Original Message-----
From: Eric Decker [mailto:[hidden email]]
Sent: Tuesday, 3 September 2013 10:57 a.m.
To: [hidden email]
Cc: Daniel Beer; GCC for MSP430 - http://mspgcc.sf.net
Subject: Re: [Mspgcc-users] msp430-gdbproxy loses connection with target


have you verified that the board is getting the voltage that you think it
should be?


On Mon, Sep 2, 2013 at 3:38 PM, Andrew McLaren <[hidden email]> wrote:


>
> On Tue, Aug 27, 2013 at 10:40:45AM +1200, Andrew McLaren wrote:
> > It would have been easy if the problem had been gdbproxy,
> but no such
> > luck. Now that mspdebug is running, I'm seeing exactly the same
> > scenario here. The messages are a tad different, but I
> think they are
> > saying the same thing. Everything works fine until mspdebug
> reports...
> >
> > fet: FET returned error code 18 (Could not determine device state)
> > fet: polling failed
> >
> > Once again, eveything appears hung outboard of mspdebug until the
> > target msp is repowered. If I simply try and restart
> mspdebug without
> > doing this, it will report;
> >
> > TI3410 device is in boot config, setting active
> > ti3410: TI_OPEN_PORT failed: A device attached to the system is not
> > functioning
> > ti3410: failed to set up port
>
> This looks like some kind of hardware problem. Have you tried
> different USB ports?
>
> Is the board powered externally, or does it draw power from the FET?
>
> Cheers,
> Daniel
>
I've been having a bit of a play to try and isolate it, but haven't come up
with anything conclusive (or really anthing at all).

To answer your questions
- the target board is powered by the FET
- I've tried switching USB ports, but no change.

I've also tried switching the target processor (another 439), but also no
change. The only harware I haven't yet swapped out is the FET itself, but
only have the single TI FET running. I do have an Olimex FET here, but
having a few issues at present installing the drivers for that, so that is
the next step.

The ONLY thing I have found so far that resets the problem is repowering the
target MSP, which leads me to think that is must be some context in that
that is somehow being corrupted. I'd also like to try a different MSP
variant, but none of the others I have here have the ROM space this needs
(just thinking, I do have one of the TI experimeter boards around, and that
has a fairly hefty MSP on it, so that could be worth a go).

So I have a couple of things to try. I'll keep you posted.

Andrew






--
Eric B. Decker
Senior (over 50 :-) Researcher




------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

Peter Bigot-4
MSP430FG4618 erratum TB18: MOV to TBCTL may clear TBR.

http://www.ti.com/lit/er/slaz368c/slaz368c.pdf page 9.

Peter


On Tue, Sep 17, 2013 at 11:09 PM, Andrew McLaren <[hidden email]>wrote:

> Just to close the loop on this, I think I have found the problem (or at
> least what the 439 MSP doesn't like).
>
> The logic maintains a reference timebase using the timer B module (this
> simply ticks away in the background and maintains a reference counter). To
> obtain a time reference at any time, the logic stops the timer block, reads
> the TBR, and restarts the timer block. Nothing really fancy there.
>
> It was a bit of luck, but the only other relatively large MSP I had
> available was the 4618 on an experimenters board. This also has a USART, so
> there were only minimal code changes needed between the 439 and the 4618
> (the 4618 is a USART1 rather than a USART0, and that was pretty much it).
> However, the 4618 timer logic failed - when the timer was restarted, the
> TBR
> was cleared, whereas the 439 restarted (as expected) from where the TBR was
> stopped. This lead me to have a good look at how the timer block was
> stopped
> and restarted.
>
> To stop and restart the timer, the whole TBCTL was being rewritten, along
> the lines of;
> TBCTL = TBSSEL_1 | ID_3 | MC_0, and
> TBCTL = TBSSEL_1 | ID_3 | MC_2
>
> This worked fine on the 439 (or at least appeared to work fine!). However
> stopping the timer block this way appeared to clear the TBR on the 4618,
> even though the TBCLR bit wasn't being set. To get this to work correctly
> on
> the 4618, I modified this to just touch the mode control bits, along the
> lines of;
> TBCTL = TBCTL & ~MC0 & ~MC1
> TBCTL = (TBCTL & ~MC0) | MC1
>
> This resolved the timer issues with the 4618, which now ran the logic with
> no problems. Moreover, the logic functioned without any of the loss of
> connectivity with the JTAG seen with the 439. Just out of curiousity, I
> rebuilt the logic for the 439 and ran that again, and it also worked 100%.
> I
> could turn the JTAG connectivity issues on and off simply by how I was
> touching the TBCTL register.
>
> A bit more playing and looking at the full TBCTL before I modify it, the
> only difference between two two is that in the first case TBIFG is being
> cleared, whereas in the modified case this is being left at its set state.
> As I'm not using TBIE or TBIFG, this doesn't affect me at all. While the
> second TBCTL strategy is explicitly only touching what is required, so is
> probably better, I can't see why the initial strategy should have caused
> any
> issues (and also why it should have cleared the TBR on 4618, but luckily it
> did!).
>
> Its curiousity value now, but if anyone can give me any insights into why
> this has happened, I'd like to know! Thanks for the help and pointers in
> resolving this.
>
> Andrew
>
> -----Original Message-----
> From: Eric Decker [mailto:[hidden email]]
> Sent: Tuesday, 3 September 2013 10:57 a.m.
> To: [hidden email]
> Cc: Daniel Beer; GCC for MSP430 - http://mspgcc.sf.net
> Subject: Re: [Mspgcc-users] msp430-gdbproxy loses connection with target
>
>
> have you verified that the board is getting the voltage that you think it
> should be?
>
>
> On Mon, Sep 2, 2013 at 3:38 PM, Andrew McLaren <[hidden email]>
> wrote:
>
>
> >
> > On Tue, Aug 27, 2013 at 10:40:45AM +1200, Andrew McLaren wrote:
> > > It would have been easy if the problem had been gdbproxy,
> > but no such
> > > luck. Now that mspdebug is running, I'm seeing exactly the same
> > > scenario here. The messages are a tad different, but I
> > think they are
> > > saying the same thing. Everything works fine until mspdebug
> > reports...
> > >
> > > fet: FET returned error code 18 (Could not determine device state)
> > > fet: polling failed
> > >
> > > Once again, eveything appears hung outboard of mspdebug until the
> > > target msp is repowered. If I simply try and restart
> > mspdebug without
> > > doing this, it will report;
> > >
> > > TI3410 device is in boot config, setting active
> > > ti3410: TI_OPEN_PORT failed: A device attached to the system is not
> > > functioning
> > > ti3410: failed to set up port
> >
> > This looks like some kind of hardware problem. Have you tried
> > different USB ports?
> >
> > Is the board powered externally, or does it draw power from the FET?
> >
> > Cheers,
> > Daniel
> >
>
> I've been having a bit of a play to try and isolate it, but haven't come up
> with anything conclusive (or really anthing at all).
>
> To answer your questions
> - the target board is powered by the FET
> - I've tried switching USB ports, but no change.
>
> I've also tried switching the target processor (another 439), but also no
> change. The only harware I haven't yet swapped out is the FET itself, but
> only have the single TI FET running. I do have an Olimex FET here, but
> having a few issues at present installing the drivers for that, so that is
> the next step.
>
> The ONLY thing I have found so far that resets the problem is repowering
> the
> target MSP, which leads me to think that is must be some context in that
> that is somehow being corrupted. I'd also like to try a different MSP
> variant, but none of the others I have here have the ROM space this needs
> (just thinking, I do have one of the TI experimeter boards around, and that
> has a fairly hefty MSP on it, so that could be worth a go).
>
> So I have a couple of things to try. I'll keep you posted.
>
> Andrew
>
>
>
>
>
>
> --
> Eric B. Decker
> Senior (over 50 :-) Researcher
>
>
>
>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>

------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

Andrew McLaren
I spoke too soon...
 
Thanks for the pointer Peter. At least that could explain the implicit
TBCLR. The code is in C so a I'm a little removed from the machine code the
compiler produces. I had a peek at how its disassembled (the working C), and
it moves the TBCTL into a register, manipulates that, then moves the
complete register back to TBCTL. I've yet to compare this to the code
originally produced, but I suspect C generated logic will always operate
this way, rather than directly on the peripherals' registers. The erratum
does say 'may'?
 
Sadly, the underlying problem hasn't disappeared, just become rather more
intermittent. It can now take hours to appear on the 4618, possibly less
time on the 439, but its hard to be absolute. All I am certain about is that
something in my logic is upsetting the MSP, but once it happens I've lost
connectivity with the MSP to be able to isolate it.
 
Eric earlier made a comment re the board voltages, so while I've had the
experimenters board running, I took the opportunity of powering this locally
rather than via the FET, but no change in outcome. I also ran the logic
disconnected from the FET overnight (its running an RF heartbeat, so could
keep some track that it was still alive), and this also failed after a
number of hours, so whatever is wrong (assuming its the same thing) is not
just upsetting the JTAG interface.
 
I'm back to the drawing board!
 
Andrew
 

 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Peter Bigot
Sent: Wednesday, 18 September 2013 10:15 p.m.
To: [hidden email]
Cc: Eric Decker; GCC for MSP430 - http://mspgcc.sf.net
Subject: Re: [Mspgcc-users] msp430-gdbproxy loses connection with target



MSP430FG4618 erratum TB18: MOV to TBCTL may clear TBR.

http://www.ti.com/lit/er/slaz368c/slaz368c.pdf page 9.

Peter



On Tue, Sep 17, 2013 at 11:09 PM, Andrew McLaren <[hidden email]>
wrote:


Just to close the loop on this, I think I have found the problem (or at
least what the 439 MSP doesn't like).

The logic maintains a reference timebase using the timer B module (this
simply ticks away in the background and maintains a reference counter). To
obtain a time reference at any time, the logic stops the timer block, reads
the TBR, and restarts the timer block. Nothing really fancy there.

It was a bit of luck, but the only other relatively large MSP I had
available was the 4618 on an experimenters board. This also has a USART, so
there were only minimal code changes needed between the 439 and the 4618
(the 4618 is a USART1 rather than a USART0, and that was pretty much it).
However, the 4618 timer logic failed - when the timer was restarted, the TBR
was cleared, whereas the 439 restarted (as expected) from where the TBR was
stopped. This lead me to have a good look at how the timer block was stopped
and restarted.

To stop and restart the timer, the whole TBCTL was being rewritten, along
the lines of;
TBCTL = TBSSEL_1 | ID_3 | MC_0, and
TBCTL = TBSSEL_1 | ID_3 | MC_2

This worked fine on the 439 (or at least appeared to work fine!). However
stopping the timer block this way appeared to clear the TBR on the 4618,
even though the TBCLR bit wasn't being set. To get this to work correctly on
the 4618, I modified this to just touch the mode control bits, along the
lines of;
TBCTL = TBCTL & ~MC0 & ~MC1
TBCTL = (TBCTL & ~MC0) | MC1

This resolved the timer issues with the 4618, which now ran the logic with
no problems. Moreover, the logic functioned without any of the loss of
connectivity with the JTAG seen with the 439. Just out of curiousity, I
rebuilt the logic for the 439 and ran that again, and it also worked 100%. I
could turn the JTAG connectivity issues on and off simply by how I was
touching the TBCTL register.

A bit more playing and looking at the full TBCTL before I modify it, the
only difference between two two is that in the first case TBIFG is being
cleared, whereas in the modified case this is being left at its set state.
As I'm not using TBIE or TBIFG, this doesn't affect me at all. While the
second TBCTL strategy is explicitly only touching what is required, so is
probably better, I can't see why the initial strategy should have caused any
issues (and also why it should have cleared the TBR on 4618, but luckily it
did!).

Its curiousity value now, but if anyone can give me any insights into why
this has happened, I'd like to know! Thanks for the help and pointers in
resolving this.

Andrew


-----Original Message-----
From: Eric Decker [mailto:[hidden email]]
Sent: Tuesday, 3 September 2013 10:57 a.m.
To: [hidden email]
Cc: Daniel Beer; GCC for MSP430 - http://mspgcc.sf.net
Subject: Re: [Mspgcc-users] msp430-gdbproxy loses connection with target


have you verified that the board is getting the voltage that you think it
should be?


On Mon, Sep 2, 2013 at 3:38 PM, Andrew McLaren <[hidden email]> wrote:


>
> On Tue, Aug 27, 2013 at 10:40:45AM +1200, Andrew McLaren wrote:
> > It would have been easy if the problem had been gdbproxy,
> but no such
> > luck. Now that mspdebug is running, I'm seeing exactly the same
> > scenario here. The messages are a tad different, but I
> think they are
> > saying the same thing. Everything works fine until mspdebug
> reports...
> >
> > fet: FET returned error code 18 (Could not determine device state)
> > fet: polling failed
> >
> > Once again, eveything appears hung outboard of mspdebug until the
> > target msp is repowered. If I simply try and restart
> mspdebug without
> > doing this, it will report;
> >
> > TI3410 device is in boot config, setting active
> > ti3410: TI_OPEN_PORT failed: A device attached to the system is not
> > functioning
> > ti3410: failed to set up port
>
> This looks like some kind of hardware problem. Have you tried
> different USB ports?
>
> Is the board powered externally, or does it draw power from the FET?
>
> Cheers,
> Daniel
>
I've been having a bit of a play to try and isolate it, but haven't come up
with anything conclusive (or really anthing at all).

To answer your questions
- the target board is powered by the FET
- I've tried switching USB ports, but no change.

I've also tried switching the target processor (another 439), but also no
change. The only harware I haven't yet swapped out is the FET itself, but
only have the single TI FET running. I do have an Olimex FET here, but
having a few issues at present installing the drivers for that, so that is
the next step.

The ONLY thing I have found so far that resets the problem is repowering the
target MSP, which leads me to think that is must be some context in that
that is somehow being corrupted. I'd also like to try a different MSP
variant, but none of the others I have here have the ROM space this needs
(just thinking, I do have one of the TI experimeter boards around, and that
has a fairly hefty MSP on it, so that could be worth a go).

So I have a couple of things to try. I'll keep you posted.

Andrew






--
Eric B. Decker
Senior (over 50 :-) Researcher





----------------------------------------------------------------------------
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151
<http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> &iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users





------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

William Swanson-2
In reply to this post by Andrew McLaren
On Tue, Sep 17, 2013 at 9:09 PM, Andrew McLaren <[hidden email]> wrote:
> The logic maintains a reference timebase using the timer B module (this
> simply ticks away in the background and maintains a reference counter). To
> obtain a time reference at any time, the logic stops the timer block, reads
> the TBR, and restarts the timer block. Nothing really fancy there.

Why are you stopping the timer? I understand that the timer updates
asynchronously, so the value may not be stable, but you can get around
that by taking multiple readings until you see two that are the same:

unsigned read_timer(void)
{
    unsigned base, sample;
    sample = TB0R;
    do {
        base = sample;
        sample = TB0R;
    } while (base != sample);
    return sample;
}

Given the device erratum, this approach would probably make more
sense. It works as long as the clock is somewhat slower than your CPU
clock (like 16x slower).

-William

------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

Jesse Frey
When I need to read a timer asynchronously do three consecutive reads and
do a bitwize majority function on them.


On Wed, Sep 18, 2013 at 11:08 PM, William Swanson <[hidden email]>wrote:

> On Tue, Sep 17, 2013 at 9:09 PM, Andrew McLaren <[hidden email]>
> wrote:
> > The logic maintains a reference timebase using the timer B module (this
> > simply ticks away in the background and maintains a reference counter).
> To
> > obtain a time reference at any time, the logic stops the timer block,
> reads
> > the TBR, and restarts the timer block. Nothing really fancy there.
>
> Why are you stopping the timer? I understand that the timer updates
> asynchronously, so the value may not be stable, but you can get around
> that by taking multiple readings until you see two that are the same:
>
> unsigned read_timer(void)
> {
>     unsigned base, sample;
>     sample = TB0R;
>     do {
>         base = sample;
>         sample = TB0R;
>     } while (base != sample);
>     return sample;
> }
>
> Given the device erratum, this approach would probably make more
> sense. It works as long as the clock is somewhat slower than your CPU
> clock (like 16x slower).
>
> -William
>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>

------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

William Swanson-2
On Thu, Sep 19, 2013 at 12:44 PM, Jesse Frey <[hidden email]> wrote:
> When I need to read a timer asynchronously do three consecutive reads and do
> a bitwize majority function on them.

Not to take this thread too far off-topic, but that approach doesn't
work. For example, say your middle reading happens to catch the timer
just as it is rolling over from 0xffff to 0x0000. Your three readings
would then be:

0xffff
0xff00 /* meta-stable transition state */
0x0000

Your bit-wise majority function would return 0xff00, which is still
wrong. Since the whole point of taking multiple readings is to avoid
these meta-stable transition states, a bit-wise majority isn't good
enough. You need to compare whole values until you see two that match.

-William

------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

Peter Bigot-4
Yeah, this is pretty far from mspgcc, but still on topic for MSP430.

There are three timer read solutions I use in BSP430, depending on the
relative speed of the clocks:

* If the clock source is synchronous to mclk, just read the counter.

* If it's asynchronous and is significantly slower, read the counter
repeatedly until two consecutive values are equal.

* If it's asynchronous and is about the same speed or faster than MCLK
dedicate a capture/compare register configured to capture both edges and
keep CCIS1 set, then toggle CCIS0 in the CCTL register to latch the counter
value.

There's an amusing little gotcha in that last one: if the timer clock is
slower than MCLK and you have SCS set, the captured count might not be
correct (SCS delays the capture until the next falling edge of the timer
clock).

Take into account that sometimes you need to also record the CCTL value and
know that it's consistent with the CCR value you select.   For example,
when trying to produce a 32-bit counter value you need to know whether an
overflow has been recorded.  My belief in the case of the
two-consecutive-reads-that-match solution is that the CCTL value between
the two reads will be correct; unfortunately the MSP430 user's guides don't
give enough detail on exactly how the clock updates are done to guarantee
that.

And be careful about reading CCR from within an interrupt handler triggered
by CCIFG, because if you use the IV interface the value you read might not
be the one that triggered the interrupt (clearing CCIFG enables an
overwrite of the captured value that would otherwise be signalled by the
COV bit).

http://pabigot.github.io/bsp430/timer_8h.html#h_periph_timer_hpl has some
additional details.  examples/platform/trxeb/timer_scs_test/main.c and
examples/misc/syncap/main.c both demonstrate some of the edge cases of
timer capture.



On Thu, Sep 19, 2013 at 3:08 PM, William Swanson <[hidden email]>wrote:

> On Thu, Sep 19, 2013 at 12:44 PM, Jesse Frey <[hidden email]> wrote:
> > When I need to read a timer asynchronously do three consecutive reads
> and do
> > a bitwize majority function on them.
>
> Not to take this thread too far off-topic, but that approach doesn't
> work. For example, say your middle reading happens to catch the timer
> just as it is rolling over from 0xffff to 0x0000. Your three readings
> would then be:
>
> 0xffff
> 0xff00 /* meta-stable transition state */
> 0x0000
>
> Your bit-wise majority function would return 0xff00, which is still
> wrong. Since the whole point of taking multiple readings is to avoid
> these meta-stable transition states, a bit-wise majority isn't good
> enough. You need to compare whole values until you see two that match.
>
> -William
>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>

------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

Andrew McLaren
Back 100% on topic, William's (and other's) suggestions make total sense -
if there is a known issue with rewriting the TxCTL register, why go there.
 
Other than the initial setup of the TBCTL (which I'll get around to with a
bit of embedded macro), I've gone and removed all instances where the TBCTL
is rewritten, and used the dual read strategy to read the TBR (my TBR is
incrementing every 250 odd uS, so substantially slower than the system
clock). I left the logic running via the debugger last night, and as of this
morning it's still happily ticking away. This is on the 439, where the
longest I've seen without issues previously was the order of 10 minutes.
 
I'm assuming this is all related to the same issue noted in the errata, but
this only refers to the possibility of implicitly clearing the TxR if a MOV
to the TxCTL is performed. What I have been seeing is rather more serious,
where this appears to be corrupting something within the MSP itself, to the
degree that the JTAG is no longer operational, and the MSP has to be power
cycled to recover. This is particularly nasty because the loss of the JTAG
effectively disables any ability to look inside with a debugger and isolate
what is happening. In many ways it feels that it was pure luck that we
stumbled across this - switching to the 4618 changed how the Timer B
behaved, which led to the MOV issues with the TxCTL.
 
Now that I feel we are getting some handle on this, I'll put a bit of effort
into trying to isolate a simple scenario that demonstrates this. I'm
surprised that this hasn't been noted previously, which makes me suspicious
that there is still something else I am doing that could be contributing.
Assuming that this can be isolated to the TxCTL MOV operations, where should
I take this from here? It feels like something that should be noted in the
errata.
 
Thanks everyone for the help and suggestions. It definitely feels like a
bright light at the end of a very long and dark tunnel!
 
Andrew

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Peter Bigot
Sent: Friday, 20 September 2013 10:05 a.m.
To: William Swanson
Cc: Jesse Frey; GCC for MSP430 - http://mspgcc.sf.net; [hidden email]
Subject: Re: [Mspgcc-users] msp430-gdbproxy loses connection with target


Yeah, this is pretty far from mspgcc, but still on topic for MSP430.

There are three timer read solutions I use in BSP430, depending on the
relative speed of the clocks:


* If the clock source is synchronous to mclk, just read the counter.


* If it's asynchronous and is significantly slower, read the counter
repeatedly until two consecutive values are equal.


* If it's asynchronous and is about the same speed or faster than MCLK
dedicate a capture/compare register configured to capture both edges and
keep CCIS1 set, then toggle CCIS0 in the CCTL register to latch the counter
value.


There's an amusing little gotcha in that last one: if the timer clock is
slower than MCLK and you have SCS set, the captured count might not be
correct (SCS delays the capture until the next falling edge of the timer
clock).


Take into account that sometimes you need to also record the CCTL value and
know that it's consistent with the CCR value you select.   For example, when
trying to produce a 32-bit counter value you need to know whether an
overflow has been recorded.  My belief in the case of the
two-consecutive-reads-that-match solution is that the CCTL value between the
two reads will be correct; unfortunately the MSP430 user's guides don't give
enough detail on exactly how the clock updates are done to guarantee that.


And be careful about reading CCR from within an interrupt handler triggered
by CCIFG, because if you use the IV interface the value you read might not
be the one that triggered the interrupt (clearing CCIFG enables an overwrite
of the captured value that would otherwise be signalled by the COV bit).


http://pabigot.github.io/bsp430/timer_8h.html#h_periph_timer_hpl has some
additional details.  examples/platform/trxeb/timer_scs_test/main.c and
examples/misc/syncap/main.c both demonstrate some of the edge cases of timer
capture.




On Thu, Sep 19, 2013 at 3:08 PM, William Swanson <[hidden email]>
wrote:


On Thu, Sep 19, 2013 at 12:44 PM, Jesse Frey <[hidden email]> wrote:
> When I need to read a timer asynchronously do three consecutive reads and
do
> a bitwize majority function on them.


Not to take this thread too far off-topic, but that approach doesn't
work. For example, say your middle reading happens to catch the timer
just as it is rolling over from 0xffff to 0x0000. Your three readings
would then be:

0xffff
0xff00 /* meta-stable transition state */
0x0000

Your bit-wise majority function would return 0xff00, which is still
wrong. Since the whole point of taking multiple readings is to avoid
these meta-stable transition states, a bit-wise majority isn't good
enough. You need to compare whole values until you see two that match.


-William

----------------------------------------------------------------------------
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151
<http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> &iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users




------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msp430-gdbproxy loses connection with target

Andrew McLaren
In reply to this post by Andrew McLaren
The good news is that this has now been solidly running a couple of days
without a glitch.
 
On the negative side, I haven't been able to isolate this purely to
rewriting the TBCTL register - doing this in isolation seems to have no side
effects other than the documented spurious TBR clears. Something else I am
doing is exacerbating this, but haven't a clue what.
 
As it looks like everything is now running 100%, I'm putting this to bed.
 
Andrew

-----Original Message-----
From: Andrew McLaren [mailto:[hidden email]]
Sent: Saturday, 21 September 2013 11:22 a.m.
To: 'Peter Bigot'; 'William Swanson'
Cc: 'Jesse Frey'; 'GCC for MSP430 - http://mspgcc.sf.net'
Subject: RE: [Mspgcc-users] msp430-gdbproxy loses connection with target


Back 100% on topic, William's (and other's) suggestions make total sense -
if there is a known issue with rewriting the TxCTL register, why go there.
 
Other than the initial setup of the TBCTL (which I'll get around to with a
bit of embedded macro), I've gone and removed all instances where the TBCTL
is rewritten, and used the dual read strategy to read the TBR (my TBR is
incrementing every 250 odd uS, so substantially slower than the system
clock). I left the logic running via the debugger last night, and as of this
morning it's still happily ticking away. This is on the 439, where the
longest I've seen without issues previously was the order of 10 minutes.
 
I'm assuming this is all related to the same issue noted in the errata, but
this only refers to the possibility of implicitly clearing the TxR if a MOV
to the TxCTL is performed. What I have been seeing is rather more serious,
where this appears to be corrupting something within the MSP itself, to the
degree that the JTAG is no longer operational, and the MSP has to be power
cycled to recover. This is particularly nasty because the loss of the JTAG
effectively disables any ability to look inside with a debugger and isolate
what is happening. In many ways it feels that it was pure luck that we
stumbled across this - switching to the 4618 changed how the Timer B
behaved, which led to the MOV issues with the TxCTL.
 
Now that I feel we are getting some handle on this, I'll put a bit of effort
into trying to isolate a simple scenario that demonstrates this. I'm
surprised that this hasn't been noted previously, which makes me suspicious
that there is still something else I am doing that could be contributing.
Assuming that this can be isolated to the TxCTL MOV operations, where should
I take this from here? It feels like something that should be noted in the
errata.
 
Thanks everyone for the help and suggestions. It definitely feels like a
bright light at the end of a very long and dark tunnel!
 
Andrew




------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13.
http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Loading...