Re: [Openocd-development] AM3517 problems

2010-12-30 Thread Marek Vasut 
On Thursday 30 December 2010 08:41:12 Øyvind Harboe wrote:
  oyv...@titan:~/workspace/openocd$ openocd -c interface ZY1000;
  zy1000_server 127.0.0.1;jtag_khz 50 -f board/am3517evm.cfg
  Open On-Chip Debugger 0.5.0-dev-00682-g0136977 (2010-12-30-08:23)
  Licensed under GNU GPL v2
  For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
  Warn : Adapter driver 'ZY1000' did not declare which transports it
  allows; assuming legacy JTAG-only
  Info : only one transport option; autoselect 'jtag'
  50 kHz
  10 kHz
  trst_only separate trst_push_pull
  jtag_speed 6000 = JTAG clk=10 kHz
  Info : clock speed 10 kHz
  Info : JTAG tap: am35x.jrc tap/device found: 0x0b7ae02f (mfg: 0x017,
  part: 0xb7ae, ver: 0x0)
  Info : JTAG tap: am35x.dap enabled
  Info : am35x.cpu: hardware has 6 breakpoints, 2 watchpoints
  Error: JTAG-DP STICKY ERROR
  Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140
  Error: JTAG-DP STICKY ERROR
  Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140
  Error: JTAG-DP STICKY ERROR
  Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140
  Error: JTAG-DP STICKY ERROR
  
  These errors here, right ... need to investigate. Any pointers possibly ?
 
 Sorry no.
 
 Fire up the debugger on OpenOCD and see what turns up?
 
 Try an older version of OpenOCD to see if it is a regression?

This stuff was there ever since I believe. I might dig in later ... I hope it's 
still connected ? :)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [beagleboard] Flyswatter with XM

2010-12-30 Thread Antonio Borneo 
On Thu, Dec 30, 2010 at 3:42 PM, Peter Stuge pe...@stuge.se wrote:
 Jon Masters wrote:
 Oh, on a randomly off-topic engineering note, I'd love to know why the
 Flyswatter contains component Q1 (the NPN transistor) so that to do a
 system reset you don't just pull nSRST low but actually set A_nSRST high
 and have that go into Q1, which results in pulling system reset low
 indirectly. Is this because we might end up sinking a lot of current?
 Does anyone with an EE/circuit design background happen to know?

 It's not so much about current as it is about voltage. The chip
 driving the transistor only has to provide a high enough voltage to
 saturate the NPN. This is fairly easy with any digital chip. In
 return, the transistor effectively acts as an open collector output,
 which will accept a wide range of voltage levels, according to the
 transistor data, and can still pull the signal to GND when the
 transistor is saturated.

 With a good choice of transistor the driving chip can be 3V3 and the
 driven /SRST signal can be much much lower. I think this is what
 Flyswatter does.

Sorry Jon, I skipped your message since not involved in the subject.

I partially agree with Peter. The transistor can be used as a valid
voltage level shifter.

I've just checked the schematic of Flyswatter adapter. The nSRST part
is common with many JTAG adapters.
The main reason for using the transistor in these circuits is to build
a wired AND.
Wikipedia does not have a valid description for wired AND circuit,
but a reasonable one is available in
http://tams-www.informatik.uni-hamburg.de/applets/hades/webdemos/00-intro/03-stdlogic/wired-and.html

On the target board, nSRST can have many sources, e.g.:
- reset button
- watchdog circuit
- power-good detector
- JTAG
All such sources have to be combined together in a single nSRST signal.
The role is: nSRST is high when all the reset sources are high too,
equivalent to the behaviour of the AND gate
http://en.wikipedia.org/wiki/AND_gate
In this case, wired AND is a good replacement for the AND gate.

All the reset sources must have open collector output (open drain
in case of CMOS devices). It means their output can only be either at
low level or left floating.
On the target board there must be one passive pull-up, a resistor to
Vcc, that provides the high level when all the sources are floating.

Best Regards,
Antonio Borneo
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] CORTEX A8: Fix broken CPU identification

2010-12-30 Thread Antonio Borneo 
On Thu, Dec 30, 2010 at 11:54 AM, Marek Vasut marek.va...@gmail.com wrote:
  } broken_cpus[] = {
 -       { 0x8000, 0x04770002, 0x6000, imx51 },
 +       { 0x8000, 0x04770002, 0x1ba00477, 0x6000, imx51 },

Hi Marek,
your patch goes in the right direction, but I think there is a mistake.

You compare the JTAG idcode with 0x1ba00477.
This value belongs to ARM debug port, not to TI or Freescale devices.

Please check ARM documentation
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0314h/DDI0314H_coresight_components_trm.pdf
at pages 2-27 and 2-28 regarding the IDCODE.
Also, grep 00477 in openocd code, and you will find many devices
with same JTAG idcode or just different version.

So, even with your patch, we can still confuse some device with the
broken imx51.

In the same document from ARM, in table 2-6 page 2-26, there is the
list of DAP registers.
One register could be interesting for your purpose, TARGETID, that I
expect has a unique idcode from the device manufacturer.
But, the document reports it is available in SW-DP only, not in JTAG-DP.

I have no idea what could be the right check to run.

Best Regards,
Antonio Borneo
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development