> On 7/10/2014 6:50 PM, Dimiter_Popoff wrote:
>> On 10.7.2014 г. 21:20, Tim Wescott wrote:
>>>
>>> Well, probably. But conspiracy theories are more fun.
>>>
>>
>> Well well, conspiracy theories. What is your experience to back
>> your claim.
>>
>> Anyway, whatever you say. I am years past wrestling those issues,
>> have found out what I have found out, got my solutions etc.
>> I would expect people here to be somewhat more inquiring than
>> the general public (i.e. to not readily repeat what they have
>> just heard a lot of times) though - but I have always
>> been too optimistic, I guess.
>>
>> Dimiter
>
> I don't know about optimistic, but gullible for sure. I think Tim was
> writing tongue in cheek.
>
> As for you, what do you base your claim on for them wanting to "control"
> what you do with their silicon? I think it is purely about the level of
> effort they have to provide to get the maximum return. Any control of
> your design is a secondary result and not of any real interest to
> "them". I can only provide as proof that they are capitalists and
> clearly have a profit motive. You could even say they are Ferengi.
>
If it has been tongue in cheek I have simply missed that.
My point is exactly that you are saying what you say without
knowing what you are talking about.
My experience includes enough fights - some of them successful - to
get to documentation of that kind. Much of the fights are reflected on
newsgroups you do read and much of which you have read already so
I am not going to repeat myself.
Suffice it to say one manufacturer spent months after having my
NDA to provide me just with the data allowing me to program a CPLD
via JTAG having a JEDEC file. Did you ever have a product doing
that in the field, or did you ever try to get such data.
There are other manufacturers too, e.g. a processor manufacturer
simply would not give me the data on the JTAG debug facilities
(which they give to selected tool vendors), NDA or not.
Dimiter
------------------------------------------------------
Dimiter Popoff, TGI http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Reply by rickman●July 10, 20142014-07-10
On 7/10/2014 6:50 PM, Dimiter_Popoff wrote:
> On 10.7.2014 г. 21:20, Tim Wescott wrote:
>>
>> Well, probably. But conspiracy theories are more fun.
>>
>
> Well well, conspiracy theories. What is your experience to back
> your claim.
>
> Anyway, whatever you say. I am years past wrestling those issues,
> have found out what I have found out, got my solutions etc.
> I would expect people here to be somewhat more inquiring than
> the general public (i.e. to not readily repeat what they have
> just heard a lot of times) though - but I have always
> been too optimistic, I guess.
>
> Dimiter
I don't know about optimistic, but gullible for sure. I think Tim was
writing tongue in cheek.
As for you, what do you base your claim on for them wanting to "control"
what you do with their silicon? I think it is purely about the level of
effort they have to provide to get the maximum return. Any control of
your design is a secondary result and not of any real interest to
"them". I can only provide as proof that they are capitalists and
clearly have a profit motive. You could even say they are Ferengi.
--
Rick
Reply by Dimiter_Popoff●July 10, 20142014-07-10
On 10.7.2014 г. 21:20, Tim Wescott wrote:
> On Wed, 09 Jul 2014 21:12:31 -0400, rickman wrote:
>
>> On 7/9/2014 5:55 PM, Kristoff Bonne wrote:
>>> Hi Hamilton,
>>>
>>>
>>> Op maandag 7 juli 2014 06:11:21 UTC+2 schreef hamilton:
>>>> The truth is vendors (people that make chips) have some secret sauce
>>>> they want to keep secret.
>>>> So they play lose with the "JTAG Standard".
>>>> Some for good reasons, some for "just to be pissy".
>>>
>>> I do understand that the vendors want to avoid giving away information
>>> about the internal workings of their chips via the onchip debug system.
>>> I guess that is normal.
>>>
>>> But, on the other hand, JTAG is just an interface, no? It just descibed
>>> how to get to the debug-hardware. It doesn't say anything about what
>>> the hardware does or how it works.
>>> Just like any other onchip debugging interface.
>>>
>>>
>>> I fail to see how using a standardised interface is more or less
>>> "dangerous" then using your own "secret" interface.
>>
>> I don't know what "danger" has to do with anything. I don't think the
>> vendors are trying to keep any aspect of their debug interface secret.
>> Rather I expect it is more an issue of just not wanting to spend the
>> time and effort on releasing the information which would then require
>> support. You can say you would like the info even without support, but
>> once they give it out, they pretty much would need to support it without
>> generating ill will with their customers.
>>
>> It is a similar situation with the FPGA makers. In this case there may
>> be some issues with secrecy, but mostly they don't give out info on
>> generating a bit stream because it would be a lot of work to support
>> with very little upside. 99.99% of their customers are happy with the
>> provided tools and they would not sell additional chips by supporting
>> the software. Very parallel to the JTAG issue with MCU vendors.
>
> Well, probably. But conspiracy theories are more fun.
>
Well well, conspiracy theories. What is your experience to back
your claim.
Anyway, whatever you say. I am years past wrestling those issues,
have found out what I have found out, got my solutions etc.
I would expect people here to be somewhat more inquiring than
the general public (i.e. to not readily repeat what they have
just heard a lot of times) though - but I have always
been too optimistic, I guess.
Dimiter
------------------------------------------------------
Dimiter Popoff, TGI http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Reply by Tim Wescott●July 10, 20142014-07-10
On Wed, 09 Jul 2014 21:12:31 -0400, rickman wrote:
> On 7/9/2014 5:55 PM, Kristoff Bonne wrote:
>> Hi Hamilton,
>>
>>
>> Op maandag 7 juli 2014 06:11:21 UTC+2 schreef hamilton:
>>> The truth is vendors (people that make chips) have some secret sauce
>>> they want to keep secret.
>>> So they play lose with the "JTAG Standard".
>>> Some for good reasons, some for "just to be pissy".
>>
>> I do understand that the vendors want to avoid giving away information
>> about the internal workings of their chips via the onchip debug system.
>> I guess that is normal.
>>
>> But, on the other hand, JTAG is just an interface, no? It just descibed
>> how to get to the debug-hardware. It doesn't say anything about what
>> the hardware does or how it works.
>> Just like any other onchip debugging interface.
>>
>>
>> I fail to see how using a standardised interface is more or less
>> "dangerous" then using your own "secret" interface.
>
> I don't know what "danger" has to do with anything. I don't think the
> vendors are trying to keep any aspect of their debug interface secret.
> Rather I expect it is more an issue of just not wanting to spend the
> time and effort on releasing the information which would then require
> support. You can say you would like the info even without support, but
> once they give it out, they pretty much would need to support it without
> generating ill will with their customers.
>
> It is a similar situation with the FPGA makers. In this case there may
> be some issues with secrecy, but mostly they don't give out info on
> generating a bit stream because it would be a lot of work to support
> with very little upside. 99.99% of their customers are happy with the
> provided tools and they would not sell additional chips by supporting
> the software. Very parallel to the JTAG issue with MCU vendors.
Well, probably. But conspiracy theories are more fun.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Reply by Dimiter_Popoff●July 10, 20142014-07-10
On 10.7.2014 г. 04:12, rickman wrote:
> ....
> I don't know what "danger" has to do with anything. I don't think the
> vendors are trying to keep any aspect of their debug interface secret.
> Rather I expect it is more an issue of just not wanting to spend the
> time and effort on releasing the information which would then require
> support.
You want to think again. Have been through that more than once,
the reason never was about support. It is about control of who
can do what with the silicon.
Dimiter
------------------------------------------------------
Dimiter Popoff, TGI http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Reply by Tauno Voipio●July 10, 20142014-07-10
On 10.7.14 00:33, Kristoff Bonne wrote:
> Hi Tauno, all,
>
>
> I will not reply to every message (I do not want to spam this list :-) ), so I'll just reply to one or two.
> But thanks for everybody who answered in this thread.
>
>
>
> Based on the replies here and a couple of additional videos,
I think I have a bit of better understanding on how it fits together.
> I found the talk of Travis Goodspeed on this openjtag debugger and
hacking MSP430s using the JTAG interface (defcon17) quite interesting.
>
> (...)
>> Another vote for OpenOCD. The OpenOCD team has done very good job
>> taking care of the heavy lifting of JTAG debugging.
>
> OpenOCD is surely on my "to try" list, once I have the
debugging-interface that is supported by it.
>
> I did notice that the AVR dragon is not on the list of
supported hardware. I guess there are other factors that
come into play here (I guess software-interface on how
to speak to the controller).
>
The AVR debugging interface is not completely compatible with
that of the ARM's, and, IIRC, the OpenOCD work is still in
progress.
My recommendation is MSP430 for a beginner, and some Cortex-M3
or Cortex-M4 for later.
>> My experience is of FT2232-based dongles, Olimex, Amontec and TI/
>> Stellaris dev board. All work fine, as well as the ST development
>> boards. I have used them with ARM7TDMI, Cortex-M3 and Cortex-M4.
>
> Any advice on a cheap interface-device for a hobbyist?
The Stellaris development board is a nice thing: It is powered
from the USB port used for the JTAG and there is a clever piece
of logic on the board so it can also work as the USB/JTAG dongle
for external hardware. This meand that you can first learn to set
up the processor and then start to hoist the own construction up.
>> A warning about Atmel Cortex boards: There is a JTAG adapter on
>> board, called J-Link. It is nearly a standard J-Link, but the
>> USB device ID and protocol are so much bastardized that it works
>> only with Atmel Studio (which is a monster based on Microsoft
>> Visual Studio, so it is unusable for a Linux/Unix user).
The Atmel chips do work with OpenOCD, the warning is only for
the USB/JTAG adapter on the development boards.
> Well, the AVR dragon does have a jtag interface and I did notice
that both avrdude and averice have options mentioning JTAG.
> Does this mean this JTAG interface is only for 8Bit AVR devices
with a JTAG interface and not for the 32bit ARM-based AVRs?
Please see above. The term JTAG is used in about as many different
purposes as RS-232. JTAG as standardized does not specify an
interface to programming Flash or debugging the target. It is
only a peephole to the insides of the chip.
Avrdude has been working fine for me. I've never used nor needed
to attempt JTAG debugging on an AVR.
--
-TV
Reply by rickman●July 9, 20142014-07-09
On 7/9/2014 5:55 PM, Kristoff Bonne wrote:
> Hi Hamilton,
>
>
> Op maandag 7 juli 2014 06:11:21 UTC+2 schreef hamilton:
>> The truth is vendors (people that make chips) have some secret sauce
>> they want to keep secret.
>> So they play lose with the "JTAG Standard".
>> Some for good reasons, some for "just to be pissy".
>
> I do understand that the vendors want to avoid giving away information about the internal workings of their chips via the onchip debug system. I guess that is normal.
>
> But, on the other hand, JTAG is just an interface, no? It just descibed how to get to the debug-hardware. It doesn't say anything about what the hardware does or how it works.
> Just like any other onchip debugging interface.
>
>
> I fail to see how using a standardised interface is more or less "dangerous" then using your own "secret" interface.
I don't know what "danger" has to do with anything. I don't think the
vendors are trying to keep any aspect of their debug interface secret.
Rather I expect it is more an issue of just not wanting to spend the
time and effort on releasing the information which would then require
support. You can say you would like the info even without support, but
once they give it out, they pretty much would need to support it without
generating ill will with their customers.
It is a similar situation with the FPGA makers. In this case there may
be some issues with secrecy, but mostly they don't give out info on
generating a bit stream because it would be a lot of work to support
with very little upside. 99.99% of their customers are happy with the
provided tools and they would not sell additional chips by supporting
the software. Very parallel to the JTAG issue with MCU vendors.
--
Rick
Reply by Tim Wescott●July 9, 20142014-07-09
On Wed, 09 Jul 2014 14:33:42 -0700, Kristoff Bonne wrote:
> Hi Taunoo, all,
>
>
> I will not reply to every message (I do not want to spam this list :-)
> ), so I'll just reply to one or two.
>
> But thanks for everybody who answered in this thread.
>
>
>
> Based on the replies here and a couple of additional videos, I think I
> have a bit of better understanding on how it fits together.
>
> I found the talk of travis Goodspeed on this openjtag debugger and
> hacking MSP430s using the JTAG interface (defcon17) quite interesting.
>
>
>
>
>>> As Richard mentioned, different processor vendors' JTAG setups are,
>>> well,
>>> different.
>
> If I get it correct, the IEEE document only describes layers 1 and 2,
> i.e. how a way to access the onchip debug logic of an IC and that's
> about it.
>
> Not very much then. :-(
>
>
>
>>> The exception is that the ARM Cortex (or maybe just the Cortex M) JTAG
>>> interface is standard. In that case there is a "generic" setup. I've
>>> used the Olimex JTAG adapter successfully on two different
>>> manufacturer's Cortex M parts (M3 and M4), and I've used the ST Link
>>> adapter successfully on ST parts (Cortex M0 and M4) and NXP (Cortex
>>> M0) parts.
>
> (...)
>> Another vote for OpenOCD. The OpenOCD team has done very good job
>> taking care of the heavy lifting of JTAG debugging.
>
> OpenOCD is surely on my "to try" list, once I have the
> debugging-interface that is supported by it.
>
> I did notice that the AVR dragon is not on the list of supported
> hardware. I guess there are other factors that come into play here (I
> guess software-interface on how to speak to the controller).
>
>
>
>> My experience is of FT2232-based dongles, Olimex, Amontec and TI/
>> Stellaris dev board. All work fine, as well as the ST development
>> boards. I have used them with ARM7TDMI, Cortex-M3 and Cortex-M4.
>
> Any advice on a cheap interface-device for a hobbyist?
You can get ARM Cortex M0 parts (the NXP LPC811M001JDH16FP) for $1.61 in
qty 1 from DigiKey, and an ST-Link debugger for $29.95 from the same
place (I think the LPC811M001JDH16FP will work with Olimex, but you need
to use up two more pins). You can use the gnu ARM tools from CodeSourcery
to do your development, and use Eclipse for an IDE and debugging front
end.
That's pretty cheap, and the environment certainly feels 'pro' to me,
since I use it to write code for customer projects.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Reply by Kristoff Bonne●July 9, 20142014-07-09
Hi Hamilton,
Op maandag 7 juli 2014 06:11:21 UTC+2 schreef hamilton:
> The truth is vendors (people that make chips) have some secret sauce
> they want to keep secret.
> So they play lose with the "JTAG Standard".
> Some for good reasons, some for "just to be pissy".
I do understand that the vendors want to avoid giving away information about the internal workings of their chips via the onchip debug system. I guess that is normal.
But, on the other hand, JTAG is just an interface, no? It just descibed how to get to the debug-hardware. It doesn't say anything about what the hardware does or how it works.
Just like any other onchip debugging interface.
I fail to see how using a standardised interface is more or less "dangerous" then using your own "secret" interface.
> hamilton
Cheerio! Kr. Bonne.
Reply by Kristoff Bonne●July 9, 20142014-07-09
Rick,
Op maandag 7 juli 2014 05:56:07 UTC+2 schreef rickman:
> As has been observed, there are many things not specified by the IEEE
> document(s) such as the connector. I believe what is defined in the
> IEEE document(s) is how to use JTAG for boundary scan which means you
> can peek and poke the I/Os. They provide an extension mode which can be
> used for custom functions which software debug falls under.
I did see the video on the EEVBLOG about JTAG's boundary scan. Very interesting.
Is there actually open-source (linux) software for this available?