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:cire...@gmail.com]
Sent: Tuesday, 3 September 2013 10:57 a.m.
To: and...@aratika.co.nz
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 <and...@aratika.co.nz> 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
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
