Re: TI's Code Composer does not clear bss data



On 28/01/2011 13:39, Simon Clubley wrote:
On 2011-01-28, David Brown<david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

I don't know the details in this case (I haven't looked at the low-level
workings of the msp430 jtag interface). But ultimately, jtag is a silly
choice of interface for debugging - it's got a /huge/ overhead if you
want to follow all the rules correctly. Most chips that have a jtag
debugger interface have some sort of non-standard shortcut to put their
jtag interface into "debug" mode rather than testpin mode. Some of
these play well with other jtag devices, others only work well if they
are the only device on the jtag bus. While the best idea is to have a
shortcut technique that works along with other devices on the board,
it's usually only the big chips that bother. When you have an FPGA or a
processor in a 400 pin bga package, it is conceivable that you will also
have a jtag chain for testing pin connections between that package and a
bga package memory device. But I expect it is a negligible proportion
of msp430 users who will want other jtag devices on the same chain.


Interesting and I had not considered this.

[snip other equally interesting comments]

Thank you for spending the time writing a detailed writeup and covering
issues I had not considered.

As I have mentioned in the past, I am a professional programmer, but a
hobbyist when it comes to electronics work, so issues like this are ones
I am not likely to encounter and hence don't consider unless made aware of
them.

Thanks,

Simon.


A lot of people who are used to microcontrollers think of jtag as just an interface for programming and debugging microcontrollers. But in fact it is designed as a board test interface, and a jtag bus is fundamentally a huge shift register. Different devices such as memory chips, processors, fpgas, etc., are all attached to the bus in serial. Then jtag commands are clocked along the bus. Initially, you use commands that are designed to identify the devices and you have commands to put different devices in active or passive states. Then when you have picked one (or more) devices to communicate with, you clock data into their test registers and read out the results of the last test.

Early jtag-based debug interfaces used precisely this method, with all the relevant debug registers attached in the chain. But if that is, for example, 10 registers with 32 bits each, then you need to clock in 320 (plus more for the command) bits even if you just want to set a single register, and you then need to clock through another 320 (plus command) bits to read the results.

This very quickly gets extremely slow, and you need intelligent debugger interface hardware (rather than a simple USB-to-spi converter, or PC parallel port interface as used to be common). So chip designers started cheating - they added new commands to the jtag interface that are not covered by any standard (though they are allowed and ignored by other devices), to allow more efficient communication.

.