Workaround: AVR Studio 4 crashes debugging multiple sections

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

This is not a great workaround, but it's better to debug in assembly than not to debug at all:

1. Compile your code as usual into .elf, .hex, and (optionally) .eep

2. Strip all extra section code from the .elf with:

$ avr-objcopy.exe -R .sect1 -R .sect2 code.elf code.elf

(The above assumes your file is code.elf and your bootloader sections are .sect1 and .sect2. You'll have to tweak this to suit your needs.)

Do not delete your .text section.

3. In Studio 4, select "Select Platform and Device..." from the Debug menu.

4. Select your ICE and check the "Open platform options" box

5. Autoconnect and start auto-programming to burn the .hex and .eep into your AVR.

6. Start debugging

7. Studio will pop up a dialog box. Set your clock frequency and on the Debug pane, select "Don't reprogram device"

With luck, Studio will NOT crash and you will be debugging your actual code (since you've already loaded it from the .hex and .eep files). The downside of this approach is that you will have no debugging information in your added sections, but like I said, debugging those bits in assembly is better than not debugging it at all.

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

I've not had problems with crashes, but I have had problems with AVRStudio not loading some sections into flash. The older version I used wouldn't load the .bootloader section into flash. 4.72 seems to load .bootloader but doesn't load the init section.

The solution I used previously was to load the .hex file then load the .elf file.
Also when I was debugging my bootloader code I found that executing any break points while the code was loading the sector buffer would cause the following sector write operation to fail.

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

It seems that the more sections you have, the less stable Studio will be. I've got 4 sections beyond .text, so it crashes every time I try to load. I prefer the sound of your workaround, but since I crash every time, I can't try it.

gibbon wrote:
Also when I was debugging my bootloader code I found that executing any break points while the code was loading the sector buffer would cause the following sector write operation to fail.

Sure. I think that's got to be expected. You really shouldn't interfere any until the RWW section is re-enabled.

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

Gre7g wrote:
It seems that the more sections you have, the less stable Studio will be. I've got 4 sections beyond .text, so it crashes every time I try to load. I prefer the sound of your workaround, but since I crash every time, I can't try it.

I think If I had to do it over again, I would have used a function pointer table located in .bootloader to call the bootloader functions. In the main code I'd use cast to create a pointer to the table. (And then I'd check the function pointer to see if it was valid before calling it.) As it is I have two versions of my program, one that links in the bootloader stuff and the other that doesn't. (Note I'm using the bootloader to write log data directly to flash, not to update the main program)

I'm assuming that this is enough of a problem now that Atmel's going to fix avrstudio and all these problems will be history.

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

I've found that I can just do the strip every time and only worry about programming from .hex and turning off download when I am messing with the Flash update code. Studio will load the .elf just fine if those sections aren't there, so I can continue debugging on my merry way. Since those commands are never executed in general debugging, it makes no difference if they get loaded or not.

gibbon wrote:
I think If I had to do it over again, I would have used a function pointer table located in .bootloader to call the bootloader functions. In the main code I'd use cast to create a pointer to the table. (And then I'd check the function pointer to see if it was valid before calling it.)

I don't think the Harvard architecture of the AVR supports function pointers. You could use a jump table and verify that the jumps look valid, but I'll stick with stripping. It's simple and works just fine. Also, FWIW, the debug wasn't near the pain I anticipated.

gibbon wrote:
I'm assuming that this is enough of a problem now that Atmel's going to fix avrstudio and all these problems will be history.

Beats me. I guess you guys have more of a history with Atmel than I do (I'm new to AVRs), but I've acquired a healthy skepticism for the speed at which a large corporation will fix a bug that only inconveniences a few people. As a contractor, I can't afford to wait for anyone to do work for me. I have to workaround or starve.

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

Gre7g wrote:
I don't think the Harvard architecture of the AVR supports function pointers.
It does - the compiler uses IJMP to jump through a variable.

Cliff

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

Oh cool! Thanks for the tip. I had no idea.

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

Gre7g wrote:
Oh cool! Thanks for the tip. I had no idea.

Having access to function pointers again after a couple of years working with HC05's (spit) is one of the reasons I'm happy working with AVR's and gcc. They allow me to write somewhat structured code in C with no over head.

If only gcc had better support for the harvard architecture life would be sweet.

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

gibbon wrote:
If only gcc had better support for the harvard architecture life would be sweet.

Why, what's wrong with the existing support of the harvard architecture? Are you asking to be able to declare variables as 'flash' or 'const' to avoid the need for pgm_read_byte() etc?

Cliff