2011-06-15 10:24:38     Can only debug hardward board once

Document created by Aaronwu Employee on Oct 16, 2013
Version 1Show Document
  • View in full screen mode

2011-06-15 10:24:38     Can only debug hardward board once

Peter Budny (UNITED STATES)

Message: 101285   

 

Hi everyone, I'm new here (and new to my job!)... please bear with me if I leave out some details.

 

I'm trying to get Eclipse + GCC/GDB + JTAG working on Windows systems with a hardware board. I have all the tools running, but there are a couple of problems I'm trying to track down.

 

The first time I plug in the board, start gdbproxy, and connect with gdb, it works fine. If I stop gdb, start gdb again, and try to do anything, gdbproxy immediately fails with "Assertion failed: emuready, file bfin.c, line 577".

 

I tried adding the --reset flag to gdbproxy, but this didn't make a difference. I can only fix it by power cycling the hardware board.

 

Is there a step I'm missing, or is this a bug with gdbproxy?

QuoteReplyEditDelete

 

 

2011-06-17 02:11:48     Re: Can only debug hardward board once

Mike Frysinger (UNITED STATES)

Message: 101334   

 

what ICE exactly are you using ?  and what version of software ?

 

using gdbproxy/jtag in Windows isnt all that well tested.  you really should run/develop under Linux if possible ...

QuoteReplyEditDelete

 

 

2011-06-20 09:14:34     Re: Can only debug hardward board once

Peter Budny (UNITED STATES)

Message: 101479   

 

It's a custom hardware board with a FT2232HL connecting USB to JTAG... that's about the limit of my understanding, but I could get more details if you can tell me what questions to ask. :-) Unfortunately, we don't have the luxury of developing under Linux, since most of our customers are already Windows-based for VisualDSP++ (which we're trying to provide an alternative to).

 

In UrJTAG I'm using "cable gnice+"... I tried other options but this is the only one that seems to work correctly for everything else.

 

Software is all latest toolchain SVN (well, latest as of last week when I compiled it)..... gdbproxy reports itself as 0.7.2, urjtag as 0.10 #5476.

QuoteReplyEditDelete

 

 

2011-06-20 09:52:48     Re: Can only debug hardward board once

Peter Budny (UNITED STATES)

Message: 101482   

 

I just played with it some more, and found out that it's only if I've set up the PLL and SDRAM, and gdbproxy/urjtag is started with --reset. If I don't touch the PLL/SDRAM it's fine, or if I don't use --reset, it's fine.

 

For now I guess I can just leave off --reset, but I'm pretty sure I'll need it eventually... the board could be in the middle of doing audio DMA or something that would at best make annoying noises, and at worst the DMA would continue while a fresh instance of the debugger is changing the SDRAM config, which would cause problems.

 

Is there any output I can provide that would help track this down?

QuoteReplyEditDelete

 

 

2011-06-20 11:39:36     Re: Can only debug hardward board once

Mike Frysinger (UNITED STATES)

Message: 101488   

 

when it comes to FTDI parts, the only real difference between them is which wires are connected up and how.  so if you wired your ICE the same way as the gnICE+, then reusing that cable is fine.  but if you're doing it differently, you should probably add your own cable to the urjtag code.

 

dont worry though, this isnt hard.  you can see all the logic in urjtag/src/tap/cable/ft2232.c ... just search for "gnice".  and then add an entry in src/tap/cable/generic_usbconn_list.h and src/tap/cable_list.h.

 

the windows side might be a bit unstable with gdbproxy and i'm honestly not sure how long before that can be addressed.  most of the development in windows is focused on VDSP while the open source side is focused on Linux.  crossovers are somewhat of an after thought unfortunately.

 

if you could open a tracker item for the issue here, we could assign it to the relevant teams.

QuoteReplyEditDelete

 

 

2011-06-20 11:41:26     Re: Can only debug hardward board once

Mike Frysinger (UNITED STATES)

Message: 101489   

 

gdbproxy doesnt reprogram anything by default.  it simply halts the processor.  this is the opposite of what vdsp does, but imo, is much more sane.

 

you'd have to specify the --board/--init-sdram/--sdram-size/etc... options in order to have clocks programmed automatically.

Attachments

    Outcomes