Debugger hangs during download

Log in or register to post comments
Go To Last Post
5 posts / 0 new
Author
Message
mjbcswitzerland
mjbcswitzerland's picture
Level: Hangaround
Joined: Fri. May 1, 2009
Posts: 155 View posts
Location: Switzerland
#1
Posted by mjbcswitzerland: Sat. Nov 13, 2010 - 11:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All

I have been trying to solve this problem for a few weeks now but am not making any progress, so am asking again if anyone can help.

The problem is following:
- with a reference project all is fine; the debugger downloads the code to the target.

- when any existing projects are imported to AVR32 studio all build normally. If a binary is generated, it can be successfully downloaded using the programming function and the code also runs normally. But when the debugger is activated it hangs at 61%. The same is true for two projects of different sizes (always 61%) [one just 10k and the other about 70k] that have been imported. There is no error message apart from when the download is aborted (after a few minutes of waiting) indicating that here was a user interruption.

The ELF file (from which the bin is generate) seems normally valid (debug level chosen doesn't help).

So what could cause the debug download to hang in the case of these imported projects whereby standard examples work?

Regards

Mark

If anyone is interested in helping solve this I have attached a zip containing the bin and the elf (the elf is quite large since g3 debugging is set).
This is a small serial boot loader for the EVK1105 board - when it runs it blinks LED0 and there is a menu on the USART.

The bin file works correctly - downloading via AVR32 programmer. The elf seems to also cause the AVR32 debugger to hang - although probably not the same case as trying to debug since it hangs at 0%.

Attachment(s): 

Package icon serial loader project who's binary output loads and runs on an EVK1105, but elf can neither load nor debug.

Tags:

Tools, In-System Debuggers and Programmers
Top
sma
sma's picture
Level: Posting Freak
Joined: Sun. Jan 14, 2007
Posts: 1836 View posts
Location: Nantes, France
Posted by sma: Sun. Nov 14, 2010 - 10:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you play with the LOCK fuses?
can you try to program after a chiperase?
Do you run the jtag com with the osc or internal RC osc (in the target windows)

-sma

Top
mjbcswitzerland
mjbcswitzerland's picture
Level: Hangaround
Joined: Fri. May 1, 2009
Posts: 155 View posts
Location: Switzerland
Posted by mjbcswitzerland: Sun. Nov 14, 2010 - 08:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

Thanks for the reply.

There is no change after a chip erase has been performed and there are no lock bits set.

The AVR32 target (JTAGICE mkII) is set to "Crystal connected to OSC0". Other settings behave the same - with internal RC it still correctly loads BIN but hangs with ELF.

Note that there is no problem programming binaries - just ELF won't work. My feeling is that there is something in the ELF that the debugger (and programmer) doesn't like. The projects are not based on the framework (they come from stand-alone projects which work with IAR and GCC - just the debugging with AVR32 studio has proven to be impossible until now (IAR debugs perfectly).

My feeling is that AVR32 studio was developed based on the framework and so has problems when something is a bit different than expected. I have requested an ATOLLIC evaluation to see whether they have the same difficulties - maybe they can help to solve this(?).

Regards

Mark

Top
hce
hce's picture
Level: Raving Lunatic
Joined: Tue. Jan 7, 2003
Posts: 4581 View posts
Location: Oslo, Norway
Posted by hce: Mon. Nov 15, 2010 - 06:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried flashing my EVK1105 board with the ELF file you provided in the initial post, and it works fine for me. I use the following command:

avr32program program -finternal@0x80000000 -c int -E -v SerialBoot.elf

Do you use avr32program from the latest AVR32 Studio? Version 2.6? You'll find avr32program within the avr32studio/plugins/com.atmel.avr.utilities*/os/*/*/bin/ directory. I use the 64-bit Linux installation.

Quote:
> avr32program program -finternal@0x80000000 -c int -E -v SerialBoot.elf
Connected to JTAGICE mkII version 6.6, 6.6 at USB.
JTAG chip erase performed.
Unlocking flash: ================================================== 100.0%
Programming 27684 bytes in 3 segments.
Verifying flash: ================================================== 100.0%

Hans-Christian

Top
mjbcswitzerland
mjbcswitzerland's picture
Level: Hangaround
Joined: Fri. May 1, 2009
Posts: 155 View posts
Location: Switzerland
Posted by mjbcswitzerland: Mon. Nov 15, 2010 - 09:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

Many thanks.

I use AVR32 studio 2.5 since the new GCC compiler versionin 2.6 crashes when compiling the project - although it should be possible to remove the GCC plug-in and use the older version of the tool chain this deinstall menu doesn't appear as shown in the documentation - therefore 2.6 is not possible at the moment.

Unfortunately my tests using the command line show that this doesn't work on my PC - Windows 7 32 bit:

C:\MJBC\Internal\ATMEL\AVR32\Studio_Workspace\uTaskerSerialBoot\Debug>avr32progr
am program -finternal@0x80000000 -c int -E -v SerialBoot.elf
Connected to JTAGICE mkII version 6.6, 6.6 at USB.
JTAG chip erase performed.
Unlocking flash: 0.0%

As is seen it is the unlocking which hangs. I can wait forever and it doesn't move from 0%.

I break with CTRL C and it display "Unlocking page failed"

This is the same as using the programming menu from within AVR32 studio.

However, please note that this is not the main problem since it is possible to program the BIN file, which is generally faster than ELF anyway. This is more additional information to the main problem, which is that the debugger also has problems and stops loading at 61% (although the 61% probably doesn't mean much and could of course internally be similar to the ELF loading difficulty).

In addition please also note that there are a number of people working on the project (I think all using WIndows) and all report the same problem of it stopping at 61%, meaning that no one seems to have been successful in being able to debug the code just yet.

Regards

Mark

Top