---------- Forwarded message ----------
From: Laszlo Papp <[email protected]>
Date: Tue, Oct 29, 2013 at 9:57 PM
Subject: Re: [OpenOCD-devel] Assign SRST to a dedicated pin on the xds100v2
jtag adapter
To: Andreas Fritiofson <[email protected]>
Cc: ext Laszlo Papp <[email protected]>
On Tue, Oct 29, 2013 at 9:51 PM, Andreas Fritiofson <
[email protected]> wrote:
>
>
>
> On Tue, Oct 29, 2013 at 10:31 PM, Laszlo Papp <[email protected]> wrote:
>
>> On Tue, Oct 29, 2013 at 9:14 PM, Andreas Fritiofson <
>> [email protected]> wrote:
>>
>>>
>>>
>>>
>>> On Tue, Oct 29, 2013 at 9:15 PM, Laszlo Papp <[email protected]> wrote:
>>>
>>>> On Tue, Oct 29, 2013 at 8:09 PM, Andreas Fritiofson <
>>>> [email protected]> wrote:
>>>>
>>>>>
>>>>> Of course you can make SRST work over the 14-pin interface. It's
>>>>> just wires. Naturally you must deviate from the TI spec because they
>>>>> didn't
>>>>> allocate a pin for SRST. The question is which pin you have control of in
>>>>> the adapter connector (which is all pins that are under control of the
>>>>> FTDI
>>>>> chip) and which pins you can spare on the board side (probably one of the
>>>>> EMU0/1 pins since they're not used in OpenOCD anyway).
>>>>>
>>>>
>>>> Unfortunately, "of course you can" is technically wrong here. You could
>>>> only do that by modifying every single adapter for everyone. That is not
>>>> worth the hassle for us.
>>>>
>>>
>>> I'm not talking about modifying the adapters. The adapters have several
>>> signals that (most likely) are directly controllable by OpenOCD and that
>>> you probably have little or no use of on the board, such as nTRST, EMU0 and
>>> EMU1. Any of those could be suitable to use as a board level reset signal
>>> (instead of their intended function). Of course you *will* have to modify
>>> the board, to route the chosen pin to your board level reset line in an
>>> electrically compatible way, instead of to whatever that pin is connected
>>> to today. That shouldn't come as a surprise.
>>>
>>
>> No, all the pins are important for others purposes, including the
>> aforementioned.
>>
>
> You could have stated that in your OP.
>
>
>>
>>
>>>
>>> I will accept that I need to flash over serial port to get such a
>>>>>> feature done with the current establishment. :/
>>>>>>
>>>>>
>>>>> Ok, but you also said (I think) that you're prepared to
>>>>> redesign/modify the boards to route a board level reset signal to a pin in
>>>>> the debug connector (obviously not the SRST pin since there is none). Have
>>>>> you given up on that?
>>>>>
>>>>
>>>> No, major board upgrade is not planned within the next long while, but
>>>> then again: I am just reiterating the TI thread. :-) There is no unused
>>>> ftdi controller pin, so minor upgrade would not solve this.
>>>>
>>>
>>> I assumed you had a problem you wanted a solution to, why else would you
>>> post to this mailing list?
>>>
>>
>> Again, please read the thread on the TI forum. Also, read the thread (and
>> its content for the time when it was posted). I am sure you will understand
>> more thereafter.
>>
>>
> I have read it three times in its entirety and I now know it by heart. I
> still don't know what you wanted from this mailing list. I don't want to
> play detective to be able to help you. If you have something you want
> answered, please repeat your question and describe your situation in detail
> without referring to some external, largely unrelated, conversation.
> Otherwise, stop wasting our time.
>
That is the tone after which I am leaving this thread. Even though I feel
the above communication style needlessly impolite, thank you for your time.
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
