Flyswatter with XM

Hello,

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:

[jcm@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
Open On-Chip Debugger 0.5.0-dev-00620-g1892a2b (2010-11-24-13:01)
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
Warn : Found broken CPU (imx51), trying to fixup ROM Table location from
0x80000000 to 0x60000000
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x80000042, MEM_AP_TAR 0x60000000
Polling target failed, GDB will be halted. Polling again in 100ms
Polling target failed, GDB will be halted. Polling again in 300ms
Polling target failed, GDB will be halted. Polling again in 700ms
Polling target failed, GDB will be halted. Polling again in 1500ms
Polling target failed, GDB will be halted. Polling again in 3100ms
Polling target failed, GDB will be halted. Polling again in 6300ms
etc.

I haven't had chance to look at the code yet, but I think some of the
broken CPU detection/fixup stuff has changed recently. Still, the
warning about the IMX51 is concerning. What ROM table is it referring to
exactly? Is this something on the Flyswatter board? Does anyone happen
to know these things before I go digging? (I used to use BDI2000s but
they're a little expensive for home...not a huge OCD user yet).

Jon.

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:

[jcm@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 :slight_smile:

Antonio Borneo graciously provided me with an answer and I have finally
had chance to followup with some testing! It works :slight_smile: 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.vasut@gmail.com>

    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.vasut@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:

[jcm@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: 0x00000000 (mfg: 0x000,
part: 0x0000, 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:

[jcm@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 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
Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011150
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011150
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x540111c0
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x540111c0

I still have a few problems with it. For example, I have to do a "reset
halt" immediately in order to be able to halt the CPU, but after doing
that I am able to read from the registers. I would love to know of other
people's experiences as to what does and doesn't work at the moment,
especially current opinions on the debugability of a Linux kernel.

Jon.

> 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.

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.

> > <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).

Yes, that'd be cool. I don't mind testing.

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.

Try with OpenOCD master branch now. Should be fixed.