Menu
▾
▴
openocd-devel
|
From: Laurent G. <lau...@am...> - 2010-03-24 09:25:50
|
... why not jtag_khz as before or something more specific ? The adapter_khz is confusing to end-users of OpenOCD. When we will coming with the SWO we will have to specifiy a SWO frequency (baudrate) too. adapter_khz is really bad since at long term we do not know which frequency we are talking about. I vote for coming back with a jtag_khz or better jtag_tck_frequency_khz. We could think to correct this for 0.5 ! Regards, Laurent Gauch http://www.amontec.com Amontec JTAGkey : Generic USB JTAG Cable auto-sense from 1.4V to 5.5V Amontec JTAGkey-2 : Generic High-speed USB JTAG interface at 30Mhz TCK Frequency... |
|
From: David B. <da...@pa...> - 2010-03-24 16:37:24
|
On Wednesday 24 March 2010, Laurent Gauch wrote: > ... why not jtag_khz as before or something more specific ? You can still call jtag_khz, though it'll be inappropriate for SWD. (And will eventually go away.) We really don't want to need JTAG and SWD versions of every config script and event handler based on what transport is in use... > The adapter_khz is confusing to end-users of OpenOCD. > > When we will coming with the SWO we will have to specifiy a SWO > frequency (baudrate) too. Kicking in SWO trace will need to specify a few other things too, so having another clock setting won't hurt. When a UART is used to collect the SWO data, it's not likely to go at the same clock rate as SWD... > > adapter_khz is really bad since at long term we do not know which > frequency we are talking about. > > I vote for coming back with a jtag_khz or better jtag_tck_frequency_khz. So you really do NOT want to see target config files that work correctly regardless of whether they're used with JTAG -or- SWD?? THat makes no sense to me. I should be able to switch to some other debug adapter -- maybe SWD-only, or JTAG-only -- without rewriting any part of the target config file. That means minimizing the number of commands that are JTAG-specific. (or SWD-specific.) |
|
From: Laurent G. <lau...@am...> - 2010-03-24 17:28:48
|
David Brownell wrote: > On Wednesday 24 March 2010, Laurent Gauch wrote: > >> ... why not jtag_khz as before or something more specific ? >> > > You can still call jtag_khz, though it'll be inappropriate for SWD. > (And will eventually go away.) > > We really don't want to need JTAG and SWD versions of every config > script and event handler based on what transport is in use... > We do not need to write specific scipt versions for JTAG or SWD serial port, but we will have to give in the target script what is the maximum specific frequency of each serial port : 'target_jtag_max_tck_frequency_khz' 'target_swd_max_tck_frequency_khz' or removing TCK 'target_jtag_max_frequency_khz' 'target_swd_max_frequency_khz' then 'target_spi_max_frequency_khz' 'target_i2c_max_frequency_khz' Electrically, the JTAG serial port as a SPI serial port will ever have a faster frequency capability than SWD, since the JTAG has all signals as unidirectional, but the SWD play with bidirectional signal (push-pull mode), the I2C play with bidirectional signal too (open-drain mode) ... 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 ... For I, it make sense to specify the Max Frequency for each different serial port protocol (or parallel protocol TRACE) in the target script. > > >> The adapter_khz is confusing to end-users of OpenOCD. >> >> When we will coming with the SWO we will have to specifiy a SWO >> frequency (baudrate) too. >> > > Kicking in SWO trace will need to specify a few other things too, > so having another clock setting won't hurt. When a UART is used > to collect the SWO data, it's not likely to go at the same clock > rate as SWD... > > >> adapter_khz is really bad since at long term we do not know which >> frequency we are talking about. >> >> I vote for coming back with a jtag_khz or better jtag_tck_frequency_khz. >> > > So you really do NOT want to see target config files that work correctly > regardless of whether they're used with JTAG -or- SWD?? > Yes I want to see same target config file for all serial protocol, and I am sure we will have. But what I really want is target config file more robust and understandable. But, for me, the adapter_khz is really not the good way to have robust I just want to have in the target file the possibility to have something like : target_jtag_max_frequency_khz 40000 target_swd_max_frequency_khz 12000 target_spi_max_frequency_khz 50000 target_i2c_max_frequency_khz 480 This is not possible with your only adapter_khz target_xxxx_max_frequency_khz is will be a robust notation and understandable for end-user writing target script. > THat makes no sense to me. I should be able to switch to some other > debug adapter -- maybe SWD-only, or JTAG-only -- without rewriting any > part of the target config file. > > That means minimizing the number of commands that are JTAG-specific. > (or SWD-specific.) > > I vote for something like target_jtag_max_frequency_khz 40000 target_swd_max_frequency_khz 12000 target_i2c_max_frequency_khz 480 Do you too now ? Regards, Laurent http://www.amontec.com |
|
From: Mariano A. <ma...@de...> - 2010-03-24 18:06:28
|
On Wed, Mar 24, 2010 at 05:32:23PM +0100, Laurent Gauch wrote: > David Brownell wrote: > > I just want to have in the target file the possibility to have something > like : > > target_jtag_max_frequency_khz 40000 > target_swd_max_frequency_khz 12000 > target_spi_max_frequency_khz 50000 > target_i2c_max_frequency_khz 480 Not that really care, but I think you can drop "frequency". So: target_jtag_max_khz 40000 target_swd_max_khz 12000 target_spi_max_khz 50000 target_i2c_max_khz 480 -Mar. |
|
From: Øyvind H. <oyv...@zy...> - 2010-03-24 18:19:10
|
> I just want to have in the target file the possibility to have something > like : > > target_jtag_max_frequency_khz 40000 > target_swd_max_frequency_khz 12000 > target_spi_max_frequency_khz 50000 > target_i2c_max_frequency_khz 480 I think I see what you mean. A hypothetical target might be able to communicate *really fast* on SWD, but have a *slow* JTAG fallback mode for instance(or vice versa). W.r.t. naming or syntax, then perhaps a layer of indirection could be a way to go? targetspeed jtag rclk 6000 targetspeed swd 1000 Where "targetspeed" is a tcl proc that redirects to the "low level" syntax whatever that turns out to be.. -- Meet us in Paris at rts EMBEDDED SYSTEMS 2010 - March 30. and April 1. http://www.zylin.com/events_rts.html Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer |
|
From: David B. <da...@pa...> - 2010-03-24 18:54:08
|
On Wednesday 24 March 2010, Laurent Gauch wrote: > > We really don't want to need JTAG and SWD versions of every config > > script and event handler based on what transport is in use... > > > We do not need to write specific scipt versions for JTAG or SWD serial > port, but we will have to give in the target script what is the maximum > specific frequency of each serial port : > > 'target_jtag_max_tck_frequency_khz' > 'target_swd_max_tck_frequency_khz' > or removing TCK > 'target_jtag_max_frequency_khz' > 'target_swd_max_frequency_khz' If the adapter needs different settings for each ... it will know which one to apply, based on the transport which has been enabled. > then > > 'target_spi_max_frequency_khz' > 'target_i2c_max_frequency_khz' |
|
From: David B. <da...@pa...> - 2010-03-24 19:11:40
|
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. > 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. > 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!) |
|
From: Laurent G. <lau...@am...> - 2010-03-25 08:42:22
|
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. |
|
From: David B. <da...@pa...> - 2010-03-24 19:50:03
|
On Wednesday 24 March 2010, Laurent Gauch wrote: > > We really don't want to need JTAG and SWD versions of every config > > script and event handler based on what transport is in use... > > > We do not need to write specific scipt versions for JTAG or SWD serial > port, but we will have to give in the target script what is the maximum > specific frequency of each serial port : > > 'target_jtag_max_tck_frequency_khz' > 'target_swd_max_tck_frequency_khz' JTAG and SWD share key signals though ... on both adapter and target sides. Lots of boards have a single JTAG/SWD connector. I really see *NO* good things coming from creating more ways to confuse configurations. Especially .... more *needless* confusion. |
|
From: Laurent G. <lau...@am...> - 2010-03-25 08:02:49
|
Øyvind Harboe wrote: >> I just want to have in the target file the possibility to have something >> like : >> >> target_jtag_max_frequency_khz 40000 >> target_swd_max_frequency_khz 12000 >> target_spi_max_frequency_khz 50000 >> target_i2c_max_frequency_khz 480 >> > > I think I see what you mean. > > A hypothetical target might be able to communicate *really fast* > on SWD, but have a *slow* JTAG fallback mode for instance(or > vice versa). > > W.r.t. naming or syntax, then perhaps a layer of indirection could > be a way to go? > > targetspeed jtag rclk 6000 > targetspeed swd 1000 > Good solution for me ! We should go in this way. > Where "targetspeed" is a tcl proc that redirects to the "low level" > syntax whatever that turns out to be.. > Laurent http://www.amontec.com |
|
From: Øyvind H. <oyv...@zy...> - 2010-03-25 08:17:45
|
>> targetspeed jtag rclk 6000 >> targetspeed swd 1000 >> > > Good solution for me ! We should go in this way. I'm happy with waiting a while before we decide on anything. 0.5 is a looong way off. There seems to be a consensus that fast and stable SWD is really the next real feature that would merit a release. -- Meet us in Paris at rts EMBEDDED SYSTEMS 2010 - March 30. and April 1. http://www.zylin.com/events_rts.html Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer |
|
From: Laurent G. <lau...@am...> - 2010-03-25 08:09:08
|
David Brownell wrote: > On Wednesday 24 March 2010, Laurent Gauch wrote: > >>> We really don't want to need JTAG and SWD versions of every config >>> script and event handler based on what transport is in use... >>> >>> >> We do not need to write specific scipt versions for JTAG or SWD serial >> port, but we will have to give in the target script what is the maximum >> specific frequency of each serial port : >> >> 'target_jtag_max_tck_frequency_khz' >> 'target_swd_max_tck_frequency_khz' >> or removing TCK >> 'target_jtag_max_frequency_khz' >> 'target_swd_max_frequency_khz' >> > > If the adapter needs different settings for each ... it will > know which one to apply, based on the transport which has been > enabled. > > True regarding the dongle (adapter) but NOT true regarding target . Again, having adapter_khz in the target scripts is really confusing. The mechanism provided by adapter_khz is right, but the command should be renamed. > > >> then >> >> 'target_spi_max_frequency_khz' >> 'target_i2c_max_frequency_khz' >> > > > Laurent http://www.amontec.com |
|
From: Laurent G. <lau...@am...> - 2010-03-25 08:30:36
|
David Brownell wrote: > On Wednesday 24 March 2010, Laurent Gauch wrote: > >>> We really don't want to need JTAG and SWD versions of every config >>> script and event handler based on what transport is in use... >>> >>> >> We do not need to write specific scipt versions for JTAG or SWD serial >> port, but we will have to give in the target script what is the maximum >> specific frequency of each serial port : >> >> 'target_jtag_max_tck_frequency_khz' >> 'target_swd_max_tck_frequency_khz' >> > > JTAG and SWD share key signals though ... on both adapter and target > sides. Lots of boards have a single JTAG/SWD connector. > > > Yes, lot of boards, but not all boards. Amontec has customers having JTAG daisy chains of more than 10 devices (target) on the same boards. Also, that's why we have target script and board script. At board level, if you have 3 targets in the JTAG chain, with max frequency of 15MHz 30MHz 60MHz, the max frequency of the JTAG chain will be around 15Mhz. Also, this is why we have max frequency specified in the JTAG BSDL file. But not all targets comes with BSDL. Result, we have to specify JTAG max frequency to any target script. SWD cannot support more than one device on the same port ! JTAG + RTCK is actually not really used in JTAG daisy chain structure. Laurent http://www.amontec.com > I really see *NO* good things coming from creating more ways to confuse > configurations. Especially .... more *needless* confusion. > > |
|
From: David B. <da...@pa...> - 2010-03-25 09:57:02
|
On Thursday 25 March 2010, Laurent Gauch wrote:
> Again, having adapter_khz in the target scripts is really confusing.
.... SO DON'T DO THAT!!
As repeated elsewhere ... i's board-specific, so it normally doesn't
belong there. When it's in the board config files, no confusion.
If you persist in *DOING THE WRONG THING* you will stay confused,
and things won't work right for you
There are some rare exceptions, related to hardware limitations on the
order of "chip *must* boot with oscillator of frequency <X, Y, or Z>
In those cases the reset-start event handlers in target files should be
used to set a floor on the clock rate. example (from a JTAG-only target):
# be absolutely certain the JTAG clock will work with the worst-case
# CLKIN = 24 MHz (best case: 36 MHz) even when no bootloader turns
# on the PLL and starts using it. OK to speed up after clock setup.
jtag_rclk 1500
$_TARGETNAME configure -event "reset-start" { jtag_rclk 1500 }
That "after clock setup" might be in a board's "reset-init" handler.
That's where you might set up e.g. a 30 MHz JTAG clock, once it's
known that the chip is ready for such a rate.
Thre could also be target-specific conventions about how boards pass
clock rates down to target config files.
But the basic rule remains: things that vary between boards should
never be constants in target config files.
|
|
From: David B. <da...@pa...> - 2010-03-25 10:10:01
|
On Thursday 25 March 2010, Laurent Gauch wrote: > > JTAG and SWD share key signals though ... on both adapter and target > > sides. Lots of boards have a single JTAG/SWD connector. > > > > > > > Yes, lot of boards, but not all boards. Amontec has customers having > JTAG daisy chains of more than 10 devices (target) on the same boards. That's irrelevant for dual-mode (JTAG and/or SWD) .. > Also, that's why we have target script and board script. At board level, > if you have 3 targets in the JTAG chain, with max frequency of 15MHz > 30MHz 60MHz, the max frequency of the JTAG chain will be around 15Mhz. > Also, this is why we have max frequency specified in the JTAG BSDL file. > But not all targets comes with BSDL. Result, we have to specify JTAG max > frequency to any target script. Actually by that argument -- too! -- the frequency is board-specific, not target-specific. > SWD cannot support more than one device on the same port ! > JTAG + RTCK is actually not really used in JTAG daisy chain structure. That depends entirely on the board layout. I've seen boards with a simple CPLD set up to make RCLK work on multiple targets. The key is is clock voting .... the RCLK signal going back to the adapter combines signals from multiple targets. ISTR there's a link to a TI webpage with the VHDL for that in the User's GUide, probably in the FAQ entry for adaptive clocking. |
|
From: Laurent G. <lau...@am...> - 2010-03-25 10:54:15
|
Hi David, Brownell wrote: > On Thursday 25 March 2010, Laurent Gauch wrote: > >> Again, having adapter_khz in the target scripts is really confusing. >> > > .... SO DON'T DO THAT!! > ... OK, but we do not resolve the problem by DON'T DO THAT!! Actually there are a lot of target scripts working with JTAGkey but not with JTAGkey-2, just because the JTAGkey-2 run by default at his highest 30Mhz frequency and because the target does not accept so high JTAG frequency. Note that this trouble will come with all new JTAG/SWD emulators able to run high-speed JTAG frequency from 24MHz to xxxMHz. From parallel port dongle to j-link the 12Mhz-16MHz is tolerated by the major part of target openocd supports, but NOT a 30MHz as on the amontec JTAGkey-2. @ 6MHz can connect (JTAGkey default JTAG frequency) @ 30MHz cannot connect (JTAGkey-2 default JTAG frequency) Fro me the only solution is that the target script gives the max frequency of his JTAG SWD interface, by adding adapter_khz or a similar command ? Sorry, but actually you do not provided any solution to this problem. What's your solution please? > As repeated elsewhere ... i's board-specific, so it normally doesn't > belong there. When it's in the board config files, no confusion. > > If you persist in *DOING THE WRONG THING* you will stay confused, > and things won't work right for you > I do not persist. I try to resolve a real openocd problem ! Laurent http://www.amontec.com > > There are some rare exceptions, related to hardware limitations on the > order of "chip *must* boot with oscillator of frequency <X, Y, or Z> > > In those cases the reset-start event handlers in target files should be > used to set a floor on the clock rate. example (from a JTAG-only target): > > # be absolutely certain the JTAG clock will work with the worst-case > # CLKIN = 24 MHz (best case: 36 MHz) even when no bootloader turns > # on the PLL and starts using it. OK to speed up after clock setup. > jtag_rclk 1500 > $_TARGETNAME configure -event "reset-start" { jtag_rclk 1500 } > > That "after clock setup" might be in a board's "reset-init" handler. > That's where you might set up e.g. a 30 MHz JTAG clock, once it's > known that the chip is ready for such a rate. > > > Thre could also be target-specific conventions about how boards pass > clock rates down to target config files. > > But the basic rule remains: things that vary between boards should > never be constants in target config files. > > |
|
From: Laurent G. <lau...@am...> - 2010-03-25 11:00:58
|
David Brownell wrote: > On Thursday 25 March 2010, Laurent Gauch wrote: > >>> JTAG and SWD share key signals though ... on both adapter and target >>> sides. Lots of boards have a single JTAG/SWD connector. >>> >>> >>> >>> >> Yes, lot of boards, but not all boards. Amontec has customers having >> JTAG daisy chains of more than 10 devices (target) on the same boards. >> > > That's irrelevant for dual-mode (JTAG and/or SWD) .. > > >> Also, that's why we have target script and board script. At board level, >> if you have 3 targets in the JTAG chain, with max frequency of 15MHz >> 30MHz 60MHz, the max frequency of the JTAG chain will be around 15Mhz. >> Also, this is why we have max frequency specified in the JTAG BSDL file. >> But not all targets comes with BSDL. Result, we have to specify JTAG max >> frequency to any target script. >> > > Actually by that argument -- too! -- the frequency is board-specific, > not target-specific. > > > >> SWD cannot support more than one device on the same port ! >> JTAG + RTCK is actually not really used in JTAG daisy chain structure. >> > > That depends entirely on the board layout. I've seen boards with a > simple CPLD set up to make RCLK work on multiple targets. The key is > is clock voting .... the RCLK signal going back to the adapter combines > signals from multiple targets. > > ISTR there's a link to a TI webpage with the VHDL for that in the User's > GUide, probably in the FAQ entry for adaptive clocking. > > Yes I know and we have done the 'RTCK CPLD Switch' exercise one time last year in the Amontec Labs. But it is not so easy to manage and this is why I wrote : 'JTAG + RTCK is actually *not really used* in JTAG daisy chain structure' Laurent http://www.amontec.com > > > |
|
From: David B. <da...@pa...> - 2010-03-26 22:48:58
|
On Thursday 25 March 2010, Laurent Gauch wrote: > 'JTAG + RTCK is actually *not really used* in JTAG daisy chain structure' I've worked with folk who rely on it. It might be fair to have OpenOCD emit a warning if it's configured for multi-TAP configurations ... ... except that would trigger wrongly in all OMAP and DaVinci configs, plus others. That seems like the most we should really do is make sure users get properly educated. We already tell them that not all configs can support adaptive clocking. |
|
From: David B. <da...@pa...> - 2010-03-25 12:01:04
|
On Thursday 25 March 2010, Laurent Gauch wrote: > > ... OK, but we do not resolve the problem by DON'T DO THAT!! > > Actually there are a lot of target scripts working with JTAGkey but not > with JTAGkey-2, Specifically which ones? > just because the JTAGkey-2 run by default at his highest > 30Mhz frequency and because the target does not accept so high JTAG Giving another example of "DON'T DO THAT!!!" ... just make your jtagkey2 driver use the same default speed as the original model, without needless incompatibilities. The config scripts might still be rather dubious... you would still appear to have board configs relying on random driver state instead of explicitly setting the right clock rate. But they'd work as well as "before" (switching to jtagkey-2). Yes? |
|
From: Laurent G. <lau...@am...> - 2010-03-25 14:28:24
|
David Brownell wrote: > On Thursday 25 March 2010, Laurent Gauch wrote: > >> ... OK, but we do not resolve the problem by DON'T DO THAT!! >> >> Actually there are a lot of target scripts working with JTAGkey but not >> with JTAGkey-2, >> > > Specifically which ones? > Amontec customers feedback this troubles on target/pxa270.cfg target/pxa255.cfg target/sam7se512.cfg target/netx500.cfg target/samsung_s3c2440.cfg ... Exhaustive list ? I do not know ... > > >> just because the JTAGkey-2 run by default at his highest >> 30Mhz frequency and because the target does not accept so high JTAG >> > > Giving another example of "DON'T DO THAT!!!" ... just make your > jtagkey2 driver use the same default speed as the original model, > without needless incompatibilities. > Yes, this is a workaround but not a solution. You will get the same trouble with other JTAG Dongles allowing a high JTAG frequency as <16Mhz ... Example : the STM32 specify a 10MHz in the STM32 BSDL file . %%%%%%%%Example%%%%%%%%%%%% -- This section specifies the TAP ports. For the TAP TCK port, the parameters in the brackets are: -- First Field : Maximum TCK frequency. -- Second Field: Allowable states TCK may be stopped in. attribute TAP_SCAN_CLOCK of JTCK : signal is (10.0e6, BOTH); attribute TAP_SCAN_IN of JTDI : signal is true; attribute TAP_SCAN_MODE of JTMS : signal is true; attribute TAP_SCAN_OUT of JTDO : signal is true; attribute TAP_SCAN_RESET of JTRST : signal is true; %%%%%%%%End Of Example%%%%%%%%% When using JTAGkey-2 (max 30MHz), why should we force the user to use 6MHz (JTAGkey) instead of 10MHz (max of the STM32 specification). This will be the same for a Xilinx or Altera target where the actual JTAG frequency can up to 50 to 60 Mhz ! Again, this is not a trouble coming from JTAGkey or JTAGkey-2. This is a trouble coming from openocd allowing to set a JTAG speed to high for a given target ! If we do not provide a robust fix to this problem, the users will again write their own custom .cfg, on their disk and the openocd community will never get back any new WORKING .cfg ! Any way, we have to set the set the absolute JTAG frequency of the target. As it is done in the BSDL FILE specification. ----------------------------------- T H E S O L U T I O N ----------------------------------- The solution is to add the absolute max frequency for a given device when we create a "jtag newtap" as jtag newtap $_CHIPNAME cpu .-freqmax_khz 10000 -irlen 7 -ircapture 0x1 -irmask 0x7f -expected-id $_CPUTAPID -expected-id $_CPUTAPID2 This will be the smarter solution I think adding to jtag newtap -freqmax_khz xxxxxx If -freqmax_khz not present (as now) let openocd to use the max frequency of the Dongle (as 30MHz for the Amontec JTAGkey-2) What do you think. I hope this is the way to go, and we keep the adapter_khz as it is now, to control 'temporary' the JTAG frequency (e.g. startup JTAG frequency ...) Laurent http://www.amontec.com > The config scripts might still be rather dubious... you would still > appear to have board configs relying on random driver state instead > of explicitly setting the right clock rate. > > But they'd work as well as "before" (switching to jtagkey-2). Yes? > > All is great with both Amontec JTAGkey and Amontec JTAGkey-2 (the JTAGkey-3 is really promizing too), they works very well with OpenOCD . That's nice. The users can switch from one to an other, without any difficulty. But the notion of frequency in the actual openocd do not let take all advantages of the speed of the Amontec JTAGkey-2 :-) Laurent http://www.amontec.com |
|
From: Laurent G. <lau...@am...> - 2010-03-26 15:57:03
|
> > David Brownell wrote: > >/ On Thursday 25 March 2010, Laurent Gauch wrote: > />/ > />>/ ... OK, but we do not resolve the problem by DON'T DO THAT!! > />>/ > />>/ Actually there are a lot of target scripts working with JTAGkey but not > />>/ with JTAGkey-2, > />>/ > />/ > />/ Specifically which ones? > />/ > / > Amontec customers feedback this troubles on > > target/pxa270.cfg > target/pxa255.cfg > target/sam7se512.cfg > target/netx500.cfg > target/samsung_s3c2440.cfg > ... > Exhaustive list ? I do not know ... > > >/ > />/ > />>/ just because the JTAGkey-2 run by default at his highest > />>/ 30Mhz frequency and because the target does not accept so high JTAG > />>/ > />/ > />/ Giving another example of "DON'T DO THAT!!!" ... just make your > />/ jtagkey2 driver use the same default speed as the original model, > />/ without needless incompatibilities. > />/ > /Yes, this is a workaround but not a solution. You will get the same > trouble with other JTAG Dongles allowing a high JTAG frequency as <16Mhz ... > Example : the STM32 specify a 10MHz in the STM32 BSDL file . > > %%%%%%%%Example%%%%%%%%%%%% > -- This section specifies the TAP ports. For the TAP TCK port, the > parameters in the brackets are: > -- First Field : Maximum TCK frequency. > -- Second Field: Allowable states TCK may be stopped in. > > attribute TAP_SCAN_CLOCK of JTCK : signal is (10.0e6, BOTH); > attribute TAP_SCAN_IN of JTDI : signal is true; > attribute TAP_SCAN_MODE of JTMS : signal is true; > attribute TAP_SCAN_OUT of JTDO : signal is true; > attribute TAP_SCAN_RESET of JTRST : signal is true; > %%%%%%%%End Of Example%%%%%%%%% > > When using JTAGkey-2 (max 30MHz), why should we force the user to use > 6MHz (JTAGkey) instead of 10MHz (max of the STM32 specification). > This will be the same for a Xilinx or Altera target where the actual > JTAG frequency can up to 50 to 60 Mhz ! > > Again, this is not a trouble coming from JTAGkey or JTAGkey-2. This is a > trouble coming from openocd allowing to set a JTAG speed to high for a > given target ! > > If we do not provide a robust fix to this problem, the users will again > write their own custom .cfg, on their disk and the openocd community > will never get back any new WORKING .cfg ! > > Any way, we have to set the set the absolute JTAG frequency of the target. > > As it is done in the BSDL FILE specification. > > ----------------------------------- > T H E S O L U T I O N > ----------------------------------- > > The solution is to add the absolute max frequency for a given device > when we create a "jtag newtap" as > jtag newtap $_CHIPNAME cpu -freqmax_khz 10000 -irlen 7 -ircapture 0x1 > -irmask 0x7f -expected-id $_CPUTAPID -expected-id $_CPUTAPID2 > > This will be the smarter solution I think adding to jtag newtap > -freqmax_khz xxxxxx > > If -freqmax_khz not present (as now) let openocd to use the max > frequency of the Dongle (as 30MHz for the Amontec JTAGkey-2) > > What do you think. I hope this is the way to go, and we keep the > adapter_khz as it is now, to control 'temporary' the JTAG frequency > (e.g. startup JTAG frequency ...) > > Laurent > http://www.amontec.com > > > >/ The config scripts might still be rather dubious... you would still > />/ appear to have board configs relying on random driver state instead > />/ of explicitly setting the right clock rate. > />/ > />/ But they'd work as well as "before" (switching to jtagkey-2). Yes? > />/ > />/ > /All is great with both Amontec JTAGkey and Amontec JTAGkey-2 (the > JTAGkey-3 is really promizing too), they works very well with OpenOCD . > That's nice. > The users can switch from one to an other, without any difficulty. > > But the notion of frequency in the actual openocd do not let take all > advantages of the speed of the Amontec JTAGkey-2 :-) > > Laurent > http://www.amontec.com > We have to implement an arg as -freqmax_khz xxxxx when creating a new TAP (jtag newtap ... -freqmax_khz 10000 ...) ? -freqmax_khz ? or -freqmaxkhz ? Please vote. Thanks. Regards, Laurent http://www.amontec.com |
|
From: David B. <da...@pa...> - 2010-03-26 22:39:51
|
On Friday 26 March 2010, Laurent Gauch wrote: > Please vote. Thanks. > Don't bother voting. That's not how we've ever worked. However, do remember that by far the bulk of the noise on $SUBJECT derives from Laurent being unwilling to fix a gratuitous incompatibility in driver support for two different Amontec products. Remove the incompatability, and most symptoms will just vanish. Or related, the futile expecation that un-initialized hardware (clocking, in this case) should behave in some predictable but hardware-generic, way. I for one don't feel I've received valid responses to even a tenth of the responses I've made the time to provide ... makin me wonder if there's any point in further discussion (strongly suspeting there i none). |
|
From: David B. <da...@pa...> - 2010-03-26 22:39:51
|
On Thursday 25 March 2010, Laurent Gauch wrote:
> David Brownell wrote:
> > On Thursday 25 March 2010, Laurent Gauch wrote:
> >
> >> ... OK, but we do not resolve the problem by DON'T DO THAT!!
> >>
> >> Actually there are a lot of target scripts working with JTAGkey but not
> >> with JTAGkey-2,
> > Specifically which ones?
> >
>
> Amontec customers feedback this troubles on
>
> target/pxa270.cfg
> target/sam7se512.cfg
> target/samsung_s3c2440.cfg
> target/netx500.cfg
> ...
hose dsn't even touch clocking, so the issue must be
the gratuitous driver incompatibility you've introduced
(with default clocking of jtagkey-2 much faster).
That is ... the *incompatibility* is from your driver.
While the root cause is clearly customer setups relying
on random driver state in the first place. "Don't do
that". There's a reason why you're supposed to initialize
hardware before relying on it to act initialized...
> target/pxa255.cfg
That one defaults the clock to a safe 300 KHz. SO if that fails,
eeither (a) there's another bug in your driver, or (b)
there's some other bug (unrelated):
# PXA255 comes out of reset using 3.6864 MHz oscillator.
# Until the PLL kicks in, keep the JTAG clock slow enough
# that we get no errors.
adapter_khz 300
$_TARGETNAME configure -event "reset-start" { adapter_khz 300 }
Innocuous.
|
|
From: David B. <da...@pa...> - 2010-03-26 22:39:51
|
On Thursday 25 March 2010, Laurent Gauch wrote:
> Again, this is not a trouble coming from JTAGkey or JTAGkey-2. This is a
> trouble coming from openocd allowing to set a JTAG speed to high for a
> given target !
>
Nope.
The problem is from *setting it too fast".
Not from "allowing it" to be set.
As they say ... PEBKAC. ("problem exists between keyboard and chair.")
If it hurts, stop applying the hammer to your thumb, or
your head to the brick wall.
|
|
From: Antonio B. <bor...@gm...> - 2010-03-25 15:00:32
|
On Thu, Mar 25, 2010 at 9:31 PM, Laurent Gauch <lau...@am...> wrote: > T H E S O L U T I O N ----------------------------------- > > The solution is to add the absolute max frequency for a given device when we > create a "jtag newtap" as > jtag newtap $_CHIPNAME cpu .-freqmax_khz 10000 -irlen 7 -ircapture 0x1 > -irmask 0x7f -expected-id $_CPUTAPID -expected-id $_CPUTAPID2 Laurent, just my 2 cents contribution.... Give a look at tcl/interface/parport.cfg This interface has one default parameter for parallel port address. The default value can be modified, e.g., in the user configuration script, without any need to change the interface script. Can similar arrangement work for you too? Best Regards Antonio Borneo |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X