Re: 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

-----Original Message-----
From: [email protected] [mailto:[email protected]] 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; [email protected]
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 <[email protected]>
wrote:


On Thu, Sep 19, 2013 at 12:44 PM, Jesse Frey <[email protected]> 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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users