Re: [Openocd-development] adapter_khz ...

[Laurent G. <lau...@am...>]

David Brownell wrote:
> On Wednesday 24 March 2010, Laurent Gauch wrote:
>   
>> Electrically, the JTAG serial port as a SPI serial port will ever have a 
>> faster frequency capability than SWD,
>>     
>
> Yet ... the same wire is used for JTAG/TCK -or- SWD/SWCLK.  And the
> same pin on the target/chip uses that as an input, and gates that clock
> against the same CPU clock.  So "Electrically" there's no reason to think
> they'd be very different.
>   
True regarding target (device), but wrong regarding board level.

For a board level, you may have a board with multiple STM32 JTAG + 
multiple CPLD in the same JTAG chain. The JTAG max freq will depend on 
the specification of all the targets in the same chain.

>
>   
>> since the JTAG has all signals as  
>> unidirectional, but the SWD play with bidirectional signal (push-pull 
>> mode),
>>     
>
> And there's an explicit turnaround delay as part of the SWD protocol,
> after switching directions on the SWDIO signal.
>   
Right.
>
>   
>> the I2C play with bidirectional signal too (open-drain mode) ... 
>>     
>
>  I2C has rise times as part of the protocol, and uses both clock stretching
> and arbitration to slow things down.  Maybe the high speed 3.4 MBit/sec mode
> works a bit differently, but that's hardly common.  (Even "Fm+", at 1 Mbit/sec
> isn't as widespread as classic 100 KHz or 400 KHz style...
>
>
>   
>> with adapter_khz only, we will not be able to specify a JTAG frequency 
>> faster than SWD frequency, and what about we will have I2C protocol ...
>>     
>
> See above for reasons that clocking JTAG very differently from than SWD seems
> somewhat foolish at a basic electrical level.
>
> If the adapter can't obey I2C clock stretching and arbitration rules,
> it shouldn't claim to support I2C.  (Not that we have such a debug
> transport defined yet... I expect SWD will come first!)
>
>
>
>   
correct.