Debugging a c++ program

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

I have used the WinAVR compiler for some weeks now, and written a C++ program for an AT90CAN128 with external RAM.

I have read the "Known issues" in Studio, I have the newest version AVR Studio 4.11 Service Pack 2 and Windows XP service pack2..

Knowing support for C++ is not complete yet, I have some questions and observations.

When I watch the "this" pointer, I can not see base class member variables when watching an instance of a derived class. Is this supported ?

Debugging a small program residing in internal RAM only, source level stepping seems not working as well (entering ASM) as a larger program with variables in external RAM, which works quite well in the source level..

When I have made several steps/breaks in the program, AVR Studio can get unstable, it may issue:

"Error reading memory SRAM Address:256 Size 28"
or
"Platform has been disconnected, leaving debug mode."
or
"Error stepping over."

Also clicking the step button too fast can give problems.
Exiting and then entering Studio increases stability for a while.

At this stage this is just observations. If I have mentioned something new, and the team wants to go for it, I will use some time to attempt making a smaller program demonstrating the problem(s).

Besides this, I still think AVR Studio is a very nice tool. It handles virtual functions also, and in my opinion, the AVR with the tools is good at doing the C++ job. Removing a few rough edges makes this a very good environment for such a "small" processor.

Despite of the mentioned "problems", AVR Studio solves the debugging job for my program.

Erik

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

Hi Erik.

Thanks for testing the C++ support in AVR Studio.
I assume that you are compiling with the -gdwarf-2 option.

1. Viewing base class members from the this pointer is not supported. (yet)
2. I am not familiar with the source-level debugging problems in small C++ programs.
3. The problem with many breakpoints is not known either.

Which target are you using?
I don't know when I will get around to providing C++ support, but I will try to fix the source-level errors as soon as possible.
Could you provide me with an example-project where the source-level and breakpoint issues are present. ?

Regards,

Torleif Sandnes
Atmel AVR Software Team

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

Hi Torleif

Thanks for offering me support.

torleifs wrote:

I assume that you are compiling with the -gdwarf-2 option.

Yes

torleifs wrote:

Which target are you using ?

A board of own design with an AT90CAN128 and external SRAM.

Right now I work on something else, but I hope within the next weeks to get time to make a condensed program running on a STK500/STK501 board.

Regards
Erik

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

Hi,

I have the same problem reported
"Platform has been disconnected, leaving debug mode."
Every time I try to connect to my ATTiny2313 using my Dragon. I have the tiny set to 5V supply, 4mhz interal osc div by 8 and have been able to program it but now it is in one wire debug mode and there seems like no way back. Unfortunately this is the second device I have tried both with the same symtoms. I have my dragon set to 6.478khz (I tried it at 125khz too.) Any suggestions or help I have MLF package and they are very hard to replace plus I only have 10 pieces.

Thanks,
Michael

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

Quote:
I have the same problem reported
I doubt it, seeing that the thread is more than 2 years old. :)

The problem you are reporting is usually due to the target being switched off or the Dargon unplugged while in debug mode and not doing a "stop debug". It can also happen if the reset line gets interfered with.

If the chip is stuck in DW mode it cannot be programmed using ISP.

In order to switch of DW mode you will need to go back into a debug session and from there go into debug>dragon option and then disable DW from there.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Thanks John,

This happens every time, I tried to program the device and it worked fine then I went to debug pressed the green play button and it put it into dw mode. I cycled the power then it tried to connect and said loading program but failed with message given after a while. There is in fact no way to enter debug mode session to take it out of that mode since it fails every time I try to enter it. I have tried repowering, rebooting etc. Not an intermittent problem.

Thanks for you help,

Michael

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

Do you have a cap in the reset line? If so remove it. Remember that you will need the full 6 ISP pins connected in order to enter/exit debug mode.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

No cap or anything on reset line, yes I have all six lines connected and it can program. I have now changed the IC again and can program and run but don't dare go back into dw mode since I have no way of getting back if it fails. All the ISP lines have no components apart from the ATTiny.

Thanks again,

Michael

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

hmmm strange, perhaps you have lost the internal clock somehow on the other chips. I have had it happen with the T2313 and the Dragon. You can try and recover the chips by feeding a clock source into xtal1 if you can put them in another board perhaps.

When you tried to enter DW mode, did you have the project properly assembled/compiled with the hex file being generated? I usually do a "build and run" and if the chip is new it will start DW, if already in DW mode it will just download the code and the cursor goes to the reset vector.

By the way, I know that you don't need a pullup resistor in the reset line (alledgedly :? ) but I always use a 4K7 pullup.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Hi John,

Thanks for your help. I did have a valid hex file. I will try the pull up resistor if I get time but I will forgo dw since the code I wrote is now working (needed a few changes but found them with functional testing.) I doubt it is the clock since I did not do anything to disable the internal clock. What clock rate does the dragon use in DW mode does anyone know? I did have a low clock rate on the processor (500kHz) so perhaps it is too slow for DW to program at.

Thanks for you time and your help,

Michael.

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

By the way, Michael, please don't "hijack" an old thread like this. Instead, please post a new thread. It's just good "netiquette".

Thanks!

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!