Geoffrey Brown wrote:
We're having problem with setting the DCO to provide an accurate Baud
rate when attached to a
gdb-proxy. The DCO setting code is enabled at the beginning of our
code -- the DCO is
derived from a 33kHz crystal. When we run without
gdb everything is fine. When we run with gdb, even with no
breakpoints enabled, the DCO setting
code fails with a high probability.
It's clear that the gdb proxy polls the jtag interface when in
continue mode. We don't have the gdb
proxy code but we do have TI's debugger DLL from which I believe this
was derived. In
gdbproxy actually uses the DLL code unmodified (I fed back the necessary
changes to make it compile nicely with GCC, so these days new versions
from TI generally compile cleanly without changes).
the DLL code, the status of the processor is checked by doing a read
of the processor's
jtag control register.
Correct.
Does reading the jtag control register disrupt critical timing in the
MSP430 (e.g. timer A) ?
No.
Does the gdb proxy use a method different than the MSP430_Status
routine provided in
TI's dll to check the state of a runnning processor ?
No.
Is there a way around the difficulty we're having ?
You probably have a board so unstable the extra noise caused by the JTAG
activity is disturbing it. Most boards have no trouble of this kind.
Take a look at your 32kHz oscillator, by enabling the ACLK to come out
on an I/O pin. A number of people with flaky timing problems find this
looks very asymetric, and tends to hiccup. The usual reasons are long
leads on the crystal, no ground plane under the crystal, and badly
selected internal capacitors. You might have a problem with the crystal
just being a poor match for the MCU (load capacitance requirements, or
ESR), but the causes I listed are the usual ones. It isn't hard to get
the 430's clock right, but a surprising number of boards fail to.
Regards,
Steve
