Re: [OpenOCD-devel] [PATCH]: 7f586ef nrf51: fix checks for is_erased

2014-10-30 Thread Andrey Yurovsky
On Thu, Oct 30, 2014 at 7:58 AM, wrote: > This is an automated email from Gerrit. > > Jim Paris (j...@jtan.com) just uploaded a new patch set to Gerrit, which you > can find at http://openocd.zylin.com/2366 > > -- gerrit > > commit 7f586ef1901eb7f061974f4693bb34a968982596 > Author: Jim Paris >

Re: [OpenOCD-devel] bypassing reading DAP ID code in SWD init sequence?

2014-08-27 Thread Andrey Yurovsky
On Wed, Aug 27, 2014 at 9:33 AM, Andreas Fritiofson wrote: > > On Mon, Aug 25, 2014 at 7:37 PM, Andrey Yurovsky wrote: >> >> >> Is there a reasonable way to pass something in from the users' config >> file that would then tell the SWD layer to do a fake init

[OpenOCD-devel] bypassing reading DAP ID code in SWD init sequence?

2014-08-25 Thread Andrey Yurovsky
I've implemented "securing" the Flash on the Atmel SAMD20 (and related parts) which in itself is quite simple. To un-secure it, one must issue a chip erase via the DSU register banks (which was also very simple), however I'm unable to do this in openocd once the device is secured. The reason is t

[OpenOCD-devel] STM32L0 Flash support

2014-08-07 Thread Andrey Yurovsky
This is now working (tested on several L0 development lits) and regression tested on at least one 'L1 variant as well, so I've updated the commit message: http://openocd.zylin.com/#/c/2200/ This config will work for L0 discovery and Nucleo boards if you would like to use this or test further: http

Re: [OpenOCD-devel] How to debug JTAG or newly developed HW

2014-07-16 Thread Andrey Yurovsky
On Wed, Jul 16, 2014 at 9:49 AM, Paul Fertser wrote: > Hi, > > On Wed, Jul 16, 2014 at 09:35:55AM -0700, Andrey Yurovsky wrote: > > I don't know about you but most of my logic analyzer usage is just > checking > > things on a simple serial bus (SPI, I2S, I2C, UART,

Re: [OpenOCD-devel] How to debug JTAG or newly developed HW

2014-07-16 Thread Andrey Yurovsky
The original one is junk but the Logic-16 at least does have a CPLD and a USB front-end in it and performs devcently. Their software is NOT Windows-only, it's available for Linux, OS X, and Windows. It's not open source but they do give you two SDK's, one to write your own decoders and another to

Re: [OpenOCD-devel] STM32L)

2014-07-10 Thread Andrey Yurovsky
On Thu, Jul 10, 2014 at 4:08 PM, Andreas Fritiofson < andreas.fritiof...@gmail.com> wrote: > > On Thu, Jul 10, 2014 at 11:21 PM, Andrey Yurovsky > wrote: > >> The current implementation assumes ARMv7m (since it's for STM32L1xx) >> however STM32L0 is a Cortex

Re: [OpenOCD-devel] STM32L)

2014-07-10 Thread Andrey Yurovsky
On Thu, Jul 10, 2014 at 2:55 PM, Spencer Oliver wrote: > On 10/07/14 22:21, Andrey Yurovsky wrote: > >> A quick update: I have the refactor finished and STM32L0 supported >> however the remaining work (implementing write) is >> going to take some time since it's usi

Re: [OpenOCD-devel] STM32L)

2014-07-10 Thread Andrey Yurovsky
27, 2014 at 3:15 PM, Andrey Yurovsky wrote: > I have the L0 Flash driver mostly working and will submit it tonight or > this weekend. It's a modification to the existing stm32lx.c driver, > however I had to do some minor reflactoring because the L0 has a different > location for a

Re: [OpenOCD-devel] STM32L)

2014-06-27 Thread Andrey Yurovsky
e the driver a little more flexible with regard to those items rather than hard-coding them. So far probing (and related functionality) and erasing works, I'm testing writing and lock/unlock next : ) -Andrey On Thu, Jun 26, 2014 at 9:45 AM, Andrey Yurovsky wrote: > I'm close to h

Re: [OpenOCD-devel] STM32L)

2014-06-26 Thread Andrey Yurovsky
I'm close to having hardware and will definitely work on support if someone else isn't already. The Flash controller looks a little different from L1's but it should not be much work. On Thu, Jun 26, 2014 at 3:00 AM, Spencer Oliver wrote: > On 26 June 2014 10:17, Radek wrote: > > When the new

Re: [OpenOCD-devel] Atmel EDBG documentation includes information about trace and AVR debug

2014-05-15 Thread Andrey Yurovsky
On Thu, May 15, 2014 at 9:45 AM, Paul Fertser wrote: > Just to let you know, the official Atmel EDBG docs [1] seem to be > quite descriptive. > > I'm working on openocd support for this and will submit patches soon. This is why I was asking about where the polling of this should live, at this po

Re: [OpenOCD-devel] RFC: unified trace featutre

2014-05-12 Thread Andrey Yurovsky
On Mon, May 12, 2014 at 2:36 PM, Duane Ellis wrote: > This is not a simple thing and is not something you really want to do with > wireshark directly, indirectly yes - but not directly. > > OpenOCD should provide only the means to extract (download) the captured > trace data from the ETB (more c

Re: [OpenOCD-devel] RFC: unified trace featutre

2014-05-12 Thread Andrey Yurovsky
On Mon, May 12, 2014 at 10:04 AM, Paul Fertser wrote: > Hi, > > On Mon, May 12, 2014 at 09:39:09AM -0700, Andrey Yurovsky wrote: > > Hi folks. I'm working on adding ITM trace support for the Atmel EDBG > > (CMSIS-DAP) dongles and would like to discuss how tracing sh

[OpenOCD-devel] RFC: unified trace featutre

2014-05-12 Thread Andrey Yurovsky
Hi folks. I'm working on adding ITM trace support for the Atmel EDBG (CMSIS-DAP) dongles and would like to discuss how tracing should be implemented in general. Right now we have only one ITM trace implementation (in the stlinkv2 HLA driver) and that's done in the target polling method as well as