Re: [Openocd-development] [PATCH] CORTEX A8: Fix broken CPU identification
On Thu, Dec 30, 2010 at 11:54 AM, Marek Vasut 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
Re: [Openocd-development] [beagleboard] Flyswatter with XM
On Thu, Dec 30, 2010 at 3:42 PM, Peter Stuge 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] AM3517 problems
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
