Re: [Openocd-development] Unused symbols; Global vs Static

Pushed. Thanks! I'm fine with keeping unused, untested fn's in git history only -- 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/zy10

Re: [Openocd-development] [RFC/PATCH] CFI: simplify bufferwsize computation

Did you test it? -- 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 progr

[Openocd-development] [RFC/PATCH] CFI: simplify bufferwsize computation

Hi, in src/flash/nor/cfi.c the mathematics around computing "bufferwsize" variable is quite obscure. Current code is the result of one year old patch to introduce multi-chip flash support. In the attached patch I try to simplify the code and comment what the variable is and how it is computed. Ple

Re: [Openocd-development] Unused symbols; Global vs Static

On Wed, Mar 24, 2010 at 2:47 PM, Øyvind Harboe wrote: > Pushed. > > Thanks! Other 2 patches in this thread. The first one is straightforward since just adds the qualifier "static". The second one, instead, removes one local function not used, telnet_set_prompt(). Function's purpose is to change t

Re: [Openocd-development] load_image question

Le 24/03/2010 17:35, michal smulski a écrit : > Hi, > > I have an ARM IC with internal flash (512kbytes) and sram (64kbytes). I > am trying to write flash via jtag. The idea is to split the image into > 64kb chunks and upload them via jtag one at a time to internal SRAM; > then burn to flash. > How

[Openocd-development] [SWD] STM32Primer2 JTAG/SWD + RLink pinout + RLink protocol dump

Hello world! I had to reschedule my tasks/priorities and it looks I am totally overworked until end of June, so I will not be able to work on SWD as I wanted, sorry :-( :-( :-( However I am still able to perform part-time support towards STM32 and SWD. Currently I have captured data transfers betw

Re: [Openocd-development] xds100v2

David Brownell wrote: > Not quite. One you own the hardware you can do whatever you > like with it. > > The legal restriction has to do with using schematics/etc to > provide support for other tools. But if you create such > support and don't distribute it, you should be OK. > So if someone w

Re: [Openocd-development] load_image question

On 2010-03-24 22:35, michal smulski wrote: I have an ARM IC with internal flash (512kbytes) and sram (64kbytes). I am trying to write flash via jtag. The idea is to split the image into 64kb chunks and upload them via jtag one at a time to internal SRAM; then burn to flash. However, I can't seem

[Openocd-development] load_image question

Hi, I have an ARM IC with internal flash (512kbytes) and sram (64kbytes). I am trying to write flash via jtag. The idea is to split the image into 64kb chunks and upload them via jtag one at a time to internal SRAM; then burn to flash. However, I can't seem to find an appropriate openocd command t

Re: [Openocd-development] ST-Link with OpenOCD?

Yes, as i know, ST-Link support STM32 and STM8 only, by providing high level function for debugging. But the protocol is not available. Check mspgcc, there is a gdbproxy supporting MSP430FET tools. If there is a similar mechanism in OpenOCD, it will be very easy to support ST-Link. 2010/3/23 Spen

Re: [Openocd-development] OpenOCD - Amontec JTAGkey-2 and default JTAG TCK frequency problem - workaround - solution

On Wednesday 24 March 2010, Øyvind Harboe wrote: > I think it makes sense that target scripts now > have to work on SWD *and* JTAG and that they shouldn't really > contain anything jtag or swd specific unless there is a reason to. Exactly where I'm coming from... plus, we should avoid creating su

Re: [Openocd-development] adapter_khz ...

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

Re: [Openocd-development] adapter_khz ...

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

Re: [Openocd-development] adapter_khz ...

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

Re: [Openocd-development] adapter_khz ...

> I just want to have in the target file the possibility to have something > like : > > target_jtag_max_frequency_khz 4 > target_swd_max_frequency_khz 12000 > target_spi_max_frequency_khz 5 > target_i2c_max_frequency_khz 480 I think I see what you mean. A hypothetical target might be able

Re: [Openocd-development] adapter_khz ...

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 4 > target_swd_max_frequency_khz 12000 > target_spi_max_frequency_khz 5 > target_i

Re: [Openocd-development] OpenOCD - Amontec JTAGkey-2 and default JTAG TCK frequency problem - workaround - solution

On Wednesday 24 March 2010, Freddie Chopin wrote: > Now we'll just have to wait for someone to say that this frequency is > board specific and that none of the interface scripts should specify that... > Good point. Didn't I just send an email on that topic? :) _

Re: [Openocd-development] OpenOCD - Amontec JTAGkey-2 and default JTAG TCK frequency problem - workaround - solution

On Wednesday 24 March 2010, Øyvind Harboe wrote: > Target scripts without a adapter_khz should be fixed to have one, > otherwise the khz is undefined. Make that "board config scripts", as a rule. It's routine for different boards to use different crystals, even if they have the same chip/target .

Re: [Openocd-development] adapter_khz ...

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 e

Re: [Openocd-development] OpenOCD - Amontec JTAGkey-2 and default JTAG TCK frequency problem - workaround - solution

> I vote for 'target_jtag_max_tck_frequency_khz' . Do you ? I'm kinda white space and naming blind, so unless there is something totally outrageous going on, I'm happy to leave this to the community. I think it makes sense that target scripts now have to work on SWD *and* JTAG and that they shoul

Re: [Openocd-development] OpenOCD - Amontec JTAGkey-2 and default JTAG TCK frequency problem - workaround - solution

On 2010-03-24 15:40, Øyvind Harboe wrote: I was wondering if target configuration should *fail* if no adapter_khz has been specified so as to *force* the target/board to have some maximum adapter_khz statement. Is that better or worse than the situation today? This seems reasonable for me, but

Re: [Openocd-development] xds100v2

On Wednesday 24 March 2010, Laurent Gauch wrote: > But the XDS100vx can only be used with TI code composer. > The TI license does not authorize to use the Texas Interuments XDS100 vx > USB JTAG Emulator with other software than Composer ! Not quite. One you own the hardware you can do whatever y

Re: [Openocd-development] adapter_khz ...

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 han

Re: [Openocd-development] OpenOCD - Amontec JTAGkey-2 and default JTAG TCK frequency problem - workaround - solution

Øyvind Harboe wrote: On Wed, Mar 24, 2010 at 4:03 PM, Laurent Gauch wrote: Target scripts without a adapter_khz should be fixed to have one, otherwise the khz is undefined. So the adapter_khz do not have the good name ;-( as I just wrote to a previous message. Or the mechanism around

Re: [Openocd-development] OpenOCD - Amontec JTAGkey-2 and default JTAG TCK frequency problem - workaround - solution

On Wed, Mar 24, 2010 at 4:03 PM, Laurent Gauch wrote: >> Target scripts without a adapter_khz should be fixed to have one, >> otherwise the khz is undefined. > > So the adapter_khz do not have the good name ;-( as I just wrote to a > previous message. > Or the mechanism around the JTAG frequency i

Re: [Openocd-development] OpenOCD - Amontec JTAGkey-2 and default JTAG TCK frequency problem - workaround - solution

Target scripts without a adapter_khz should be fixed to have one, otherwise the khz is undefined. So the adapter_khz do not have the good name ;-( as I just wrote to a previous message. Or the mechanism around the JTAG frequency is wrong. A target script should not be depending on an adapter c

Re: [Openocd-development] OpenOCD - Amontec JTAGkey-2 and default JTAG TCK frequency problem - workaround - solution

> Now we'll just have to wait for someone to say that this frequency is board > specific and that none of the interface scripts should specify that... I was wondering if target configuration should *fail* if no adapter_khz has been specified so as to *force* the target/board to have some maximum a

Re: [Openocd-development] OpenOCD - Amontec JTAGkey-2 and default JTAG TCK frequency problem - workaround - solution

On 2010-03-24 15:28, Øyvind Harboe wrote: The idea is that adapter_khz should set a speed equal to or lower than the argument. If the adapter can't do as high as requested, no problem => it will set a lower speed in the target script. If the adapter driver is correctly implemented that is. Targ

Re: [Openocd-development] OpenOCD - Amontec JTAGkey-2 and default JTAG TCK frequency problem - workaround - solution

Did you read: > help adapter_khz adapter_khz [khz] With an argument, change to the specified maximum jtag speed. For JTAG, 0 KHz signifies adaptive clocking. With or without argument, display current setting. (command valid any time) > help jtag_rclk jtag_rclk [fallback_speed_k

[Openocd-development] OpenOCD - Amontec JTAGkey-2 and default JTAG TCK frequency problem - workaround - solution

Hi all, One problem occurs regarding the JTAG frequency, the JTAG Dongle and the script compatibility : The Amontec JTAGkey first generation (JTAGkey and JTAGkey Tiny) are running at a maximum 6MHz . The Amontec JTAGkey second generation (JTAGkey-2 JTAGkey-2P soon JTAGkey-2 Tiny) are running

Re: [Openocd-development] xds100v2

Hi Dave, But the XDS100vx can only be used with TI code composer. The TI license does not authorize to use the Texas Interuments XDS100 vx USB JTAG Emulator with other software than Composer ! Laurent http://www.amontec.com Amontec JTAGkey : Generic USB JTAG Cable auto

[Openocd-development] adapter_khz ...

... 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 talki

[Openocd-development] jtag_rclk ...

... why not jtag_rtck . The 'rclk' instead 'rtck' made mistake for the end-users of OpenOCD ? When we talk about JTAG we talk about TCK and RTCK signals! We could think to change this for 0.5. Regards, Laurent Gauch http://www.amontec.com ___ Openocd