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] [beagleboard] Flyswatter with XM
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. //Peter ___ 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 Mon, 2010-12-13 at 04:12 -0500, Jon Masters wrote: > On Mon, 2010-12-13 at 10:05 +0100, Marek Vasut wrote: > > On Monday 13 December 2010 10:00:05 Jon Masters wrote: > > > > > > > > > > > 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). 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? 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:12:57 Jon Masters wrote: > On Mon, 2010-12-13 at 10:05 +0100, Marek Vasut wrote: > > On Monday 13 December 2010 10:00:05 Jon Masters wrote: > > > > > > > > > > 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). Yes, that'd be cool. I don't mind testing. > > 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: > > > > > > > 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 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. > > > > > 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 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. > 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 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
> 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
>
> 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_beag
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
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
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 has 6 breakpoints, 2 watchp
