ARM-USB-162 suddenly fails to step, AVR Dragon.

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR-USB-162 was step debugging with my ARV dragon!

And then I decided to reflash the DRAGON from a VM on Linux. That's right a vm on linux !!!! Dumb huh?

(Olimex AVR-ISB-162 board.)

I was using the new Sparkfun 10-to-6 pin adapter on the ICSP port of the board to connect. I read that the little USB chip would step debug, breakpoint, etc. with the DRAGON via "debug wire" which is a 3 wire connection. Apparently this 10-to-6 wire converted maintained the correct connections because when I set the ISP frequency to 125khz on the AVRISP MKII I was able to clear the appropriate fuse bit, and after re-connecting the Dragon, it subsequently work perfectly from inside AVR Studio v. 4.18 sp3. in all regards I could test.

THEN IN MOMENT OF LUNACY I DECIDED TO RE-FLASH THE DRAGON TO UPDATE IT. This killed the connection, and the board has been dead since to both the AVRISP MkII, or Dragon as far as ID from AVR Studio. Runs programs fine. Yes I did try to use the Dragon to clear everything in High Voltage programming mode.

It claims its successful, but the test program I burned initially still is OK and that doesn't seem right to me, it should be cleared as well.

So hysteria aside. Any advice on how to re-establish my debug setup??? It was very touchy making the connection and original id, from AVR studio, but I would very much like to get it working again.

Thanks,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update: I did NOT erase the chip via the HV Programming mode, as I have not make the proper connections between the Dragon and the external board. Dicey situation that and not recommended in the Dragon doc... So that seems to be a kernel of understanding. If degug wire is enabled then the AVRISP MkII cannot work. So the issue is why isn't the Dragon now seeing the board. Borked chip I bet... time to try new board.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I presume that you have a healthy Dragon. i.e. it has current firmware and works wit other chips.

Connect the Dragon to the AT90USB162 via the ISP cable.
Disable debugWire with:

avrdragon.exe -dAT90usb162 -W

You will either need to be in the avrdragon directory, or add the full path to the command.
Personally I write little batch files that have the full path.

Once debugWire is disabled, you have a regular chip back again. Program the bootloader. Use FLIP from now on.

Debugging JTAG enabled chips is relatively foolproof.
Debugging dWire enabled chips requires a clear head.

Enable. Debug for whole session. Disable.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David,

Thanks for your reply, will try ASAP.

Have fine day, advice well taken!

Randy

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update:

Exactly so ... the command worked perfectly and both the AVR Dragon in ISP mode, and the AVR ISP MkII see the board perfectly!

I was able to experiment successfully with several flavors of boot loader, and got both the AVR dfu and LUFA bootloaders to work.

So I guess its flip for me, but am disappointed I can no longer step the board via DebugWire...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes. Of course you can single step the board with debugWire.

Your PC will run Windows. Studio will enable debugWire, do your debugging etc. So will C-SPY.

If you are determined to run Linux, you will have to struggle with avr-gdb. You can receive your medal later.

I have no idea whether Studio will run in a Windows emulator under Linux.

There are plenty of Linux users out there. There is nothing inherently wrong with Linux. It is just that a native Linux front-end to avr-gdb is nowhere near Studio or C-SPY.

When I hear otherwise, I will happily use Linux.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I have no idea whether Studio will run in a Windows emulator under Linux.

Can't think of a good reason why it wouldn't.
I use that configuration (albeit on a Mac [which after all is still an *ix core]) for deep debugging (as noted, avr-gdb is a little 'tedious').

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!