Re: [Openocd-development] [beagleboard] Flyswatter with XM
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] [beagleboard] Flyswatter with XM
Try with OpenOCD master branch now. Should be fixed. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ 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 Monday 13 December 2010 03:27:17 Jon Masters wrote:
On Wed, 2010-11-24 at 23:59 -0500, Jon Masters wrote:
Has anyone managed to get the TinCanTools Flyswatter working with the
XM? I did with the original Beagle, but upstream OCD does this with XM:
[...@constitution openocd]$ sudo /usr/local/bin/openocd
-s /usr/local/lib/openocd
-f /usr/local/share/openocd/scripts/interface/flyswatter.cfg
-f /usr/local/share/openocd/scripts/board/ti_beagleboard_xm.cfg
The following is posted for the benefit of those using Google. It is a
complete summary of this issue so I hope you find this mail first when
you have the same problem and find my messages in the archives :)
Antonio Borneo graciously provided me with an answer and I have finally
had chance to followup with some testing! It works :) As Antonio notes,
the problem is caused by some fixup logic that was added as part of some
otherwise excellent patches from Marek Vasut. In the patch:
commit 0649fb2f6c7e1bea138769ecc2ec8dc17ae98044
Author: Marek Vasut marek.va...@gmail.com
Date: Sun Oct 31 05:24:36 2010 +0100
ADIv5: Introduce function to detect ROM Table location
This patch adds function called dap_detect_debug_base(), which
should be called to get location of the ROM Table. By walking ROM
Table, it's possible to discover the location of DAP.
Sadly, some CPUs misreport this value, therefore I had to introduce
an fixup table, which will be used in case such CPU is detected.
Signed-off-by: Marek Vasut marek.va...@gmail.com
Some logic is added to detect CPU cores that report an incorrect ARM DAP
(Debug Access Port, exposed behind something called an ICEPick which
sits on the JTAG chain and allows devices to come and go - I'm still
figuring all of this out in the case of the Cortex parts). The problem
is that the iMX51 actually *DOES* correctly report the location of its
DAP and so does not need to be fixed up! As Antonio points out, the
simple fix is to comment out the following loop in
src/target/arm_adi_v5.c (reformatted for reading):
If it *DOES* report it correctly, why do they have erratum ENGcm09395 then ?
But
I assume you tested it on imx51 and it was reported correctly ?
Beagleboard isn't imx51 just fyi.
#if 0 /* JCM - comment out this for the moment (for BeagleBoard-xM) */
/* Some CPUs are messed up, so fixup if needed. */
for (i = 0; i sizeof(broken_cpus)/sizeof(struct broken_cpu); i++)
if (broken_cpus[i].dbgbase == dbgbase
broken_cpus[i].apid == apid) {
LOG_WARNING(Found broken CPU (%s), trying to fixup
ROM Table location from 0x%08x to 0x%08x,
broken_cpus[i].model, dbgbase,
broken_cpus[i].correct_dbgbase);
dbgbase = broken_cpus[i].correct_dbgbase;
break;
}
#endif
(don't forget to comment out the unsigned int i; to avoid the gcc
error that will be generated with the default flags used by OpenOCD).
This is bogus ... I'd prefer extending the detection to be able to identify
imx51 in a more precise way.
This will prevent the DAP fixup logic from incorrectly being used. There
is still no fix for this in OpenOCD master but I suspect some specific
hack can be added to make that broken_cpus table more specific, or to
have known-good models such as the one on BeagleBoard-xM be excluded.
NOTE: It is important to physically reset the Flyswatter after you patch
and re-install a working OpenOCD. Do not simply run it or you will see:
[...@constitution ~]$ sudo /usr/local/bin/openocd
-s /usr/local/lib/openocd
-f /usr/local/share/openocd/scripts/interface/flyswatter.cfg
-f /usr/local/share/opocd/scripts/board/ti_beagleboard_xm.cfg
Open On-Chip Debugger 0.5.0-dev-00651-gc6e0705-dirty (2010-12-12-19:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
10 kHz
Warn : dm37x.dsp: huge IR length 38
trst_only separate trst_push_pull
Info : clock speed 10 kHz
Info : TAP dm37x.jrc does not have IDCODE
Warn : JTAG tap: dm37x.jrc UNEXPECTED: 0x (mfg: 0x000,
part: 0x, ver: 0x0)
Error: JTAG tap: dm37x.jrc expected 1 of 1: 0x0b89102f (mfg: 0x017,
part: 0xb891, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Then the LED3 will also remain on and the Flyswatter won't work until
you unplug and reset it. After doing that, with a modified OpenOCD
otherwise based upon v0.4.0-651-gc6e0705 (today) with only the single
loop commented out for a workaround, you should see:
[...@constitution ~]$ sudo /usr/local/bin/openocd
-s /usr/local/lib/openocd
-f /usr/local/share/openocd/scripts/interface/flyswatter.cfg
-f /usr/local/share/opocd/scripts/board/ti_beagleboard_xm.cfg
Open On-Chip Debugger 0.5.0-dev-00651-gc6e0705-dirty
Re: [Openocd-development] [beagleboard] Flyswatter with XM
On Mon, 2010-12-13 at 09:45 +0100, Marek Vasut wrote: On Monday 13 December 2010 03:27:17 Jon Masters wrote: Some logic is added to detect CPU cores that report an incorrect ARM DAP (Debug Access Port, exposed behind something called an ICEPick which sits on the JTAG chain and allows devices to come and go - I'm still figuring all of this out in the case of the Cortex parts). The problem is that the iMX51 actually *DOES* correctly report the location of its DAP and so does not need to be fixed up! As Antonio points out, the simple fix is to comment out the following loop in src/target/arm_adi_v5.c (reformatted for reading): If it *DOES* report it correctly, why do they have erratum ENGcm09395 then ? But I assume you tested it on imx51 and it was reported correctly ? Beagleboard isn't imx51 just fyi. Sorry, you're right. I spent too long reading the OpenOCD source and seeing the IMX51 Freescale references in the broken_cpus array, and then it was late... Yea, I'm using the DM3730 TI processor in the BeagleBoard-xM here, which is being picked up by your logic in that loop incorrectly and a fixup is being applied that should not be applied. snip commented out code fixup This is bogus ... I'd prefer extending the detection to be able to identify imx51 in a more precise way. Sure. I was just applying a hack in my local git branch for running the BeagleBoard-xM here with my Flyswatter. That was neither a patch nor intended for use other than with the xM if someone else is using a release of OpenOCD since the beginning of November. I really agree with you that the correct fix is to better determine an IMX51 for fixup. FWIW, I got this wrong at first. I read the archives and assumed that the BeagleBoard was in need of some fixup, but actually it's fine. It's the logic intended to fixup the other part that is breaking Beagle. Oh, and hey, thanks for the followup. Jon. ___ 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 Monday 13 December 2010 10:00:05 Jon Masters wrote: On Mon, 2010-12-13 at 09:45 +0100, Marek Vasut wrote: On Monday 13 December 2010 03:27:17 Jon Masters wrote: Some logic is added to detect CPU cores that report an incorrect ARM DAP (Debug Access Port, exposed behind something called an ICEPick which sits on the JTAG chain and allows devices to come and go - I'm still figuring all of this out in the case of the Cortex parts). The problem is that the iMX51 actually *DOES* correctly report the location of its DAP and so does not need to be fixed up! As Antonio points out, the simple fix is to comment out the following loop in src/target/arm_adi_v5.c (reformatted for reading): If it *DOES* report it correctly, why do they have erratum ENGcm09395 then ? But I assume you tested it on imx51 and it was reported correctly ? Beagleboard isn't imx51 just fyi. Sorry, you're right. I spent too long reading the OpenOCD source and seeing the IMX51 Freescale references in the broken_cpus array, and then it was late... Yea, I'm using the DM3730 TI processor in the BeagleBoard-xM here, which is being picked up by your logic in that loop incorrectly and a fixup is being applied that should not be applied. snip commented out code fixup This is bogus ... I'd prefer extending the detection to be able to identify imx51 in a more precise way. Sure. I was just applying a hack in my local git branch for running the BeagleBoard-xM here with my Flyswatter. That was neither a patch nor intended for use other than with the xM if someone else is using a release of OpenOCD since the beginning of November. I really agree with you that the correct fix is to better determine an IMX51 for fixup. FWIW, I got this wrong at first. I read the archives and assumed that the BeagleBoard was in need of some fixup, but actually it's fine. It's the logic intended to fixup the other part that is breaking Beagle. Can you try checking how can that be fixed ? I believe it'd just be a matter of adding a few more identification information (check how the fixup loop detects the CPU, try extending it so it doesn't break beagle). Oh, and hey, thanks for the followup. Jon. ___ 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 Mon, 2010-12-13 at 10:05 +0100, Marek Vasut wrote: On Monday 13 December 2010 10:00:05 Jon Masters wrote: snip commented out code fixup This is bogus ... I'd prefer extending the detection to be able to identify imx51 in a more precise way. Sure. I was just applying a hack in my local git branch for running the BeagleBoard-xM here with my Flyswatter. That was neither a patch nor intended for use other than with the xM if someone else is using a release of OpenOCD since the beginning of November. I really agree with you that the correct fix is to better determine an IMX51 for fixup. FWIW, I got this wrong at first. I read the archives and assumed that the BeagleBoard was in need of some fixup, but actually it's fine. It's the logic intended to fixup the other part that is breaking Beagle. Can you try checking how can that be fixed ? I believe it'd just be a matter of adding a few more identification information (check how the fixup loop detects the CPU, try extending it so it doesn't break beagle). Sure. I don't have time today, but when I get chance this week I will take a look at better distinguishing the parts (I have only several of the Beagles here, but not the offending Freescale part so can send you a patch to test when I get chance to look at it). Jon. ___ 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 Wed, 2010-11-24 at 23:59 -0500, Jon Masters wrote:
Has anyone managed to get the TinCanTools Flyswatter working with the
XM? I did with the original Beagle, but upstream OCD does this with XM:
[...@constitution openocd]$ sudo /usr/local/bin/openocd
-s /usr/local/lib/openocd
-f /usr/local/share/openocd/scripts/interface/flyswatter.cfg
-f /usr/local/share/openocd/scripts/board/ti_beagleboard_xm.cfg
The following is posted for the benefit of those using Google. It is a
complete summary of this issue so I hope you find this mail first when
you have the same problem and find my messages in the archives :)
Antonio Borneo graciously provided me with an answer and I have finally
had chance to followup with some testing! It works :) As Antonio notes,
the problem is caused by some fixup logic that was added as part of some
otherwise excellent patches from Marek Vasut. In the patch:
commit 0649fb2f6c7e1bea138769ecc2ec8dc17ae98044
Author: Marek Vasut marek.va...@gmail.com
Date: Sun Oct 31 05:24:36 2010 +0100
ADIv5: Introduce function to detect ROM Table location
This patch adds function called dap_detect_debug_base(), which
should be called to get location of the ROM Table. By walking ROM
Table, it's possible to discover the location of DAP.
Sadly, some CPUs misreport this value, therefore I had to introduce
an fixup table, which will be used in case such CPU is detected.
Signed-off-by: Marek Vasut marek.va...@gmail.com
Some logic is added to detect CPU cores that report an incorrect ARM DAP
(Debug Access Port, exposed behind something called an ICEPick which
sits on the JTAG chain and allows devices to come and go - I'm still
figuring all of this out in the case of the Cortex parts). The problem
is that the iMX51 actually *DOES* correctly report the location of its
DAP and so does not need to be fixed up! As Antonio points out, the
simple fix is to comment out the following loop in
src/target/arm_adi_v5.c (reformatted for reading):
#if 0 /* JCM - comment out this for the moment (for BeagleBoard-xM) */
/* Some CPUs are messed up, so fixup if needed. */
for (i = 0; i sizeof(broken_cpus)/sizeof(struct broken_cpu); i++)
if (broken_cpus[i].dbgbase == dbgbase
broken_cpus[i].apid == apid) {
LOG_WARNING(Found broken CPU (%s), trying to fixup
ROM Table location from 0x%08x to 0x%08x,
broken_cpus[i].model, dbgbase,
broken_cpus[i].correct_dbgbase);
dbgbase = broken_cpus[i].correct_dbgbase;
break;
}
#endif
(don't forget to comment out the unsigned int i; to avoid the gcc
error that will be generated with the default flags used by OpenOCD).
This will prevent the DAP fixup logic from incorrectly being used. There
is still no fix for this in OpenOCD master but I suspect some specific
hack can be added to make that broken_cpus table more specific, or to
have known-good models such as the one on BeagleBoard-xM be excluded.
NOTE: It is important to physically reset the Flyswatter after you patch
and re-install a working OpenOCD. Do not simply run it or you will see:
[...@constitution ~]$ sudo /usr/local/bin/openocd
-s /usr/local/lib/openocd
-f /usr/local/share/openocd/scripts/interface/flyswatter.cfg
-f /usr/local/share/opocd/scripts/board/ti_beagleboard_xm.cfg
Open On-Chip Debugger 0.5.0-dev-00651-gc6e0705-dirty (2010-12-12-19:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
10 kHz
Warn : dm37x.dsp: huge IR length 38
trst_only separate trst_push_pull
Info : clock speed 10 kHz
Info : TAP dm37x.jrc does not have IDCODE
Warn : JTAG tap: dm37x.jrc UNEXPECTED: 0x (mfg: 0x000,
part: 0x, ver: 0x0)
Error: JTAG tap: dm37x.jrc expected 1 of 1: 0x0b89102f (mfg: 0x017,
part: 0xb891, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Then the LED3 will also remain on and the Flyswatter won't work until
you unplug and reset it. After doing that, with a modified OpenOCD
otherwise based upon v0.4.0-651-gc6e0705 (today) with only the single
loop commented out for a workaround, you should see:
[...@constitution ~]$ sudo /usr/local/bin/openocd
-s /usr/local/lib/openocd
-f /usr/local/share/openocd/scripts/interface/flyswatter.cfg
-f /usr/local/share/opocd/scripts/board/ti_beagleboard_xm.cfg
Open On-Chip Debugger 0.5.0-dev-00651-gc6e0705-dirty (2010-12-12-19:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
10 kHz
Warn : dm37x.dsp: huge IR length 38
trst_only separate trst_push_pull
Info : clock speed 10 kHz
Info : JTAG tap: dm37x.jrc tap/device found: 0x0b89102f (mfg: 0x017,
part: 0xb891, ver: 0x0)
Info : JTAG tap: dm37x.dap enabled
Info : dm37x.cpu: hardware
