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:and...@aratika.co.nz]
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
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
