Re: [Openocd-development] patch[2/2]: read target voltage first in vsllink

On Sunday 17 January 2010, simon qian wrote: > In most cases, it works, but as I tested under Ubuntu9.04, there is a chance > that the USB will fail. > If I read target voltage first, the problem disappear. > > For the lastest Versaloon firmware, it's OK. > So it's a tweak for the Old Versaloon fi

Re: [Openocd-development] patch[2/2]: read target voltage first in vsllink or Amontec JTAGkey / Amontec JTAGkey-2

Look up the power_dropout fn in openocd. Interfaces can implement support for detecting and reporting power dropouts. If the interface has the capability of reading the power at a moment in time(polling), then this is somewhat less useful as OpenOCD can not spend all it's time polling the power st

[Openocd-development] patch[2/2]: read target voltage first in vsllink or Amontec JTAGkey / Amontec JTAGkey-2

> > >/ On Sun, Jan 17, 2010 at 9:58 PM, simon qian >gmail.com > > >wrote: > />/ > The very first command after init command should be "read target > voltage". > />/ > />/ I would like the patch to have a comment *why* this should be

Re: [Openocd-development] patch[1/2]: insert space before left parenthesis

On Sun, Jan 17, 2010 at 9:56 PM, simon qian wrote: > see http://forum.sparkfun.com/viewtopic.php?p=90983#90983. > Can anybody try this? If you can confirm that this solves the problem, I would want a comment that explains why this is necessary. If somebody goes in and rewrites that code later on

Re: [Openocd-development] [patch/rfc 0/3] TMS clocking interface

>> but essentially the interface_ layer should be *told* >> what the TAP state is after a given TMS sequence. > > I don't follow.  For starters, > >> > +int jtag_add_tms_seq(unsigned nbits, uint8_t *seq, enum tap_state t); > > does pass a state. Right I need new glasses... I'll have to apply y

Re: [Openocd-development] STM32 regression - first "load" after power-up fails

>> target remote xxx >> # the target is not affected or queried by a gdb connnect. Dummy values are >> # returned and a white lie takes place w.r.t. that the target is halted. > > That "white lie" may be problematic.  However, I've only looked > a bit at the GDB remote protocol, and I suspect that

Re: [Openocd-development] OpenOCD on MX51

On Sunday 17 January 2010, Alan Carvalho de Assis wrote: > Now I need to find a way to place the processor on halt mode. I tried > many commands, including "imx51.cpu arp_halt" with no success. Use plain old "halt". "arp_halt" looks to be unused. Certainly it's not documented as anything more th

Re: [Openocd-development] STM32 regression - first "load" after power-up fails

On Sunday 17 January 2010, Øyvind Harboe wrote: > I'm not sure we have a regression here. Against 0.3.1 it seems we don't have one... Against 0.2.0 it looks like we do (did)... (If I understand correctly.) > A regression test should minimally include: > > 1. test sequence > > 2. expected resu

Re: [Openocd-development] patch[2/2]: read target voltage first in vsllink

On Sunday 17 January 2010, Øyvind Harboe wrote:   > On Sun, Jan 17, 2010 at 9:58 PM, simon qian > wrote: > > The very first command after init command should be "read target voltage". > > I would like the patch to have a comment *why* this should be > the first command. > > What happens if it i

Re: [Openocd-development] [patch/rfc 0/3] TMS clocking interface

On Sunday 17 January 2010, Øyvind Harboe wrote: > I have given this patch some more thought and it breaks > the JTAG API and jtag_add_pathmove() API/driver layer > in particular. $SUBJECT includes three patches ... which one do you mean? Also, in what sense does it "break" anything? As I noted,

Re: [Openocd-development] patch[2/2]: read target voltage first in vsllink

On Sun, Jan 17, 2010 at 9:58 PM, simon qian wrote: > The very first command after init command should be "read target voltage". I would like the patch to have a comment *why* this should be the first command. What happens if it is not? > > -- > Best Regards, SimonQian > http://www.SimonQian.com

[Openocd-development] patch[2/2]: read target voltage first in vsllink

The very first command after init command should be "read target voltage". -- Best Regards, SimonQian http://www.SimonQian.com vsllink_read_targetvoltage_first.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lis

[Openocd-development] patch[1/2]: insert space before left parenthesis

see http://forum.sparkfun.com/viewtopic.php?p=90983#90983. Can anybody try this? -- Best Regards, SimonQian http://www.SimonQian.com svf_fix_insert_space_before_left_parenthesis.patch Description: Binary data ___ Openocd-development mailing list Openo

Re: [Openocd-development] STM32 regression - first "load" after power-up fails

I'm not sure we have a regression here. A regression test should minimally include: 1. test sequence 2. expected result If we agree that both are according to OpenOCD documentation/support, and it fails on one version and not the other, then we have a regression. Could you provide 1+2? (I coul

Re: [Openocd-development] [patch/rfc 0/3] TMS clocking interface

I have given this patch some more thought and I breaks the JTAG API and jtag_add_pathmove() API/driver layer in particular. We should discuss more post 0.4(I need to choose battles before then), but essentially the interface_ layer should be *told* what the TAP state is after a given TMS sequence

Re: [Openocd-development] OpenOCD on MX51

On Sunday 17 January 2010, Alan Carvalho de Assis wrote: > I'm reading the "CoreSight Technology System Design Guide", but there > is poor information about DAP. See: ARM Debug Interface v5 Architecture Specification for DAP info... ___ Openocd-develop

Re: [Openocd-development] OpenOCD on MX51

Hi David, On 1/16/10, David Brownell wrote: > On Saturday 16 January 2010, Alan Carvalho de Assis wrote: >> I'm trying to figure out what DAP is waiting for. > > Sorry, cant help there. But surely turning on the debug > output options (there's a separate JTAG I/O option too) > should provide mor

Re: [Openocd-development] [PATCH] atmega128: implement EEPROM flashing

> Do you have anything better with JTAG OCD documentation for AVR8? I have read some, but I can not open it. > Yes, but if somebody reworked AVR support in openOCD in a sane way, it would be a matter of adding another config file, fairly trivial. In VSprog, avr8.xml is the only thing needed to be

Re: [Openocd-development] [PATCH] atmega128: implement EEPROM flashing

It will be hard if no official spec is available. But even if implemented, not all dongles supported by OpenOCD can support DW interface for Mega8. 2010/1/16 Alan Carvalho de Assis > Hi Paul, > > On 1/16/10, Paul Fertser wrote: > ... > > > >> In my programmer VSProg, I use a .xml configuration

Re: [Openocd-development] [PATCH] atmega128: implement EEPROM flashing

Yes, actually I use auto-detect for AVR8 chips both on ISP and JTAG according to the JTAG ID. So no need to specify the chip module. 2010/1/16 David Brownell > On Saturday 16 January 2010, Paul Fertser wrote: > > > If use .cfg for a AVR8 chip, there will be many such configure > > > files. > > >