How is debugWire (DWEN fuse) unprogrammed

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

Gentlemen!

 

As a sideshow to the never ending debug thread of mine, I give you this:

 

My endeavors with AVaRICE and debugWire are a failure so far. Basically, AVaRICE reports it can not enter a debugWire session.

 

I'd like to test a hypothesis that AVaRICE does not program the DWEN fuse, but that it has to be programmed when one starts AVaRICE. I suppose I can do that..

 

As I understand it, when DWEN is programmed the AVR can no longer be programmed at all using ISP since the RESET pin now is disabled as such and instead working as a kind of I/O pin.

 

The big question then becomes: How is the DWEN fuse cleared (un-programmed)? 

 

Obviously, it can be done since Studio does it. But how? Am I correct in speculating that there is some kind of "command" in the debugWire protocol that can do this? Where can I find any details on it? (I did a few searches in a ATmega88 data sheet but came out stumped.)

 

Obviously, I can do it by High-Voltage programming. And I suppose I can do it by switching over to Windows, run Studio, start a debugging session and end it properly. Both are tedious ways of re-enabling ISP. I'd like to investigate (before testing) if it might be that AVaRICE does it. Details on how it is done might help me looking through the sources.

 

Any insight most welcome!

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

There is a debugWIRE command to "Leave debugWIRE".

 

You call "Leave debugWIRE",  clear the DWEN fuse via ISP.   Job done.

 

Note that you must maintain VCC between the two steps.   Or else the AVR will Reset back to debugWIRE mode.

 

The whole operation can work very smoothly.    Rowley has always worked nicely with debugWIRE.

In contrast,  the Atmel Tools have made it difficult.

 

In Atmel's defence.   Punters will make no effort to read the docs e.g. about RESET pin having >10k pullup and no capacitors.

It is easy to enable DWEN via most programming software even with strong pullup or with capacitor.    Hence an unhappy punter.

 

David.

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

David wrote:

"In Atmel's defence.   Punters will make no effort to read the docs e.g. about RESET pin having >10k pullup and no capacitors.

 

In the ATMEGA328PB datasheet I read:

The debugWIRE Setup shows the schematic of a target MCU, with debugWIRE enabled, and the
emulator connector. The system clock is not affected by debugWIRE and will always be the clock source
selected by the CKSEL Fuses.
When designing a system where debugWIRE will be used, the following observations must be made for
correct operation:
• Pull-up resistors on the dW/(RESET) line must not be smaller than 10kΩ. The pull-up resistor is not
required for debugWIRE functionality
• Connecting the RESET pin directly to VCC will not work.
• Capacitors connected to the RESET pin must be disconnected when using debugWire.
• All external reset sources must be disconnected.
ATmega328PB
 

 Does:

"• Pull-up resistors on the dW/(RESET) line must not be smaller than 10kΩ. The pull-up resistor is not
required for debugWIRE functionality", mean that Pull-up resistors don't need to be used, but if they are used, must be > 10k?

 

 

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

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

avrdude handles this automatically, you just have to set the fuses manually.

 

If the target AVR has been set up for debugWire mode (i. e. the DWEN fuse is programmed), normal ISP connection attempts will fail as the /RESET pin is not available.
When using the JTAG ICE mkII in ISP mode, the message shown indicates that avrdude has guessed this condition, and tried to initiate a debugWire reset to the target.
When successful, this will leave the target AVR in a state where it can respond to normal ISP communication again (until the next power cycle).
Typically, the same command is going to be retried again immediately afterwards, and will then succeed connecting to the target using normal ISP communication.

I got debugging "working" on a 328P yesterday, but I didn't compile with -ggdb so it didn't work as expected. Will give it a new try with the correct settings today.

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

@meolsen: Thank you for that link, Morten!

 

Very illustrating. Can't see how I missed that. Obviously need to browse through the debugger manual(s) once again.

 


 

canbeany1 wrote:
avrdude handles this automatically, you just have to set the fuses manually.

Thank you! I obviously also need to re-read the AVRDUDE manual.

 

This gives me one more argument for doing a write-up once I feel confident enough. I've been looking around AVaRICE for this. (Maybe it's documented there also, but I've missed it...) All the pieces of this puzzle is out there somewhere, but some are in good but scattered documentation, others are in not-so-good documentation, some seems to be "you just know/learn" stuff). If others are like me (poor bastards..;-) they will be looking for a comprehensive and cohesive "how-to" (with background in explanations and/or (perma-)links).

 

Anyhow... If I get this right this means the process of getting into, and out of, debugWIRE with AVaRICE means:

 

1. Use AVRDUDE to program DWEN

2. Start AVaRICE.

3. Do debugging

4. Stop AVaRICE (somehow.. [1])

4. Use AVRDUDE to un-program DWEN (whereupon it will do it's magic as in canbeany1's quote from the man page)

 

Correct?

 


[1] Yes, how do you stop AVaRICE? Up until now, since I've only been looking for it to start and wait/listen for a GDB to connect, I've simply killed it with ctrl-C...

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:

Anyhow... If I get this right this means the process of getting into, and out of, debugWIRE with AVaRICE means:

 

1. Use AVRDUDE to program DWEN

2. Start AVaRICE.

3. Do debugging

4. Stop AVaRICE (somehow.. [1])

4. Use AVRDUDE to un-program DWEN (whereupon it will do it's magic as in canbeany1's quote from the man page)

 

Correct?

 


[1] Yes, how do you stop AVaRICE? Up until now, since I've only been looking for it to start and wait/listen for a GDB to connect, I've simply killed it with ctrl-C...

 

1. Program DWEN  with AVRDUDE

2. Power cycle MCU

3. Start AVaRICE.

4. Start and attach GDB

5. Quitting GDB with q + enter, y to confirm kill of AVaRICE. (I am also just using ctrl+c if I kill it before I attach GDB)

6. Unprogram DWEN.

 

Here you can see when I restore fuse settings, it fails using ISP.

But AVRDUDE works it's magic to quit DW, and then sends the fuse write automatically when it has got the MCU in ISP mode.

I haven't checked if the read I do first, triggers the automatic mode before the write though, going to try a manual clearing of DWEN next.

a@debian:~$ ./328fuse -d
avrdude: jtag3_edbg_prepare(): failed to read from serial port (-1)
avrdude: failed to sync with the JTAGICE3 in ISP mode
Fuse was: 0x9e
Fuse now: 0xde

avrdude: stk500v2_command(): command failed
avrdude: Target prepared for ISP, signed off.
avrdude: Now retrying without power-cycling the target.
avrdude: AVR device initialized and ready to accept instructions

Debugging is working for me now on the ATmega328P, with the asm("break") workaround as described here: http://www.luniks.net/avr-debug.jsp

Have only tried it in avr-gdb though, eclipse and ddd is next in line.

 

*edit* Oh, and sometimes you may have to unplug the ICE before AVRDUDE can find it. I have had this problem a few times when uploading from inside eclipse.

Last Edited: Mon. Sep 11, 2017 - 08:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please remember that after you either set or reset the DWEN fuse, you need to cycle power off and then back on again to actually place the uC in the debugwire mode (enable DWEN) or normal operation (disable DWEN).  I wrote batch files in Windows to enable and disable the DWEN fuse just to ECHO that reminder.  Fuses are read when the uC powers up and while Avrdude automagically switches from debugWire to ISP in order to reset the DWEN fuse, the uC will still be in the debugwire mode as long as power is applied.

 

Here is what my avrdude output looks like fpr the ATtiny84 when resetting the DWEN fuse

Reset the DWEN fuse

D:\>avrdude -pt84 -cdragon_isp -b57600 -u -Uhfuse:w:0xDf:m

avrdude: jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED

avrdude: jtagmkII_getsync(): ISP activation failed, trying debugWire

avrdude: Target prepared for ISP, signed off.

avrdude: Now retrying without power-cycling the target.

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.15s

avrdude: Device signature = 0x1e930c

avrdude: reading input file "0xDf"

avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.15s

avrdude: 1 bytes of hfuse written

avrdude: verifying hfuse memory against 0xDf:

avrdude: load data hfuse data from input file 0xDf:

avrdude: input file 0xDf contains 1 bytes

avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.05s

avrdude: verifying ...

avrdude: 1 bytes of hfuse verified

avrdude done.  Thank you.

 

Although probably obvious to most, in order to disable the DWEN fuse, you need to use a programmer that speaks debugwire like a Dragon, not an USBasp programmer.

 

Alan

 

All this info recently learned while getting debugging to work inside of Eclipse using debugwire with the Dragon attached to an ATtiny84 (Window XP and WinAVR20100110).

Last Edited: Mon. Sep 11, 2017 - 01:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You don't need to cycle power for the Leave and Disable operation. Leave gets you out of dW mode. This lets you disable DWEN via ISP. You are still in non-dW mode. Obviously a power cycle does no harm at this stage. Any subsequent power-up reads the absent DWEN fuse and starts in non-dW mode.
.
Entering dW mode is different. After enabling DWEN fuse, the power-cycle is needed to start up in dW mode.
The Leave and Disable must have power throughout. Any cycling between Leave and Disable restores the dW mode.
.
David.

Last Edited: Mon. Sep 11, 2017 - 12:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David,

 

Sounds like you are using ATmel Studio.  I'm using Eclipse with the avr-Eclipse plugin -  Eclipse does not have a "Leave and Disable" option.

 

The mode of the uC after the DWEN fuse has been reset by avrdude still confuses me.  The (recently added) avrdude  partial printout

 

D:\>avrdude -pt84 -cdragon_isp -b57600 -u -Uhfuse:w:0xDf:m

avrdude: jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED

avrdude: jtagmkII_getsync(): ISP activation failed, trying debugWire

avrdude: Target prepared for ISP, signed off.

avrdude: Now retrying without power-cycling the target.

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.15s

avrdude: Device signature = 0x1e930c

avrdude: reading input file "0xDf"

avrdude: writing hfuse (1 bytes):

 

seems to indicate that the target is switched from debugwire to ISP mode in order to reprogram the DWEN fuse.  So is the uC in the ISP mode or debugwire mode before cycling power?  You seem to indicate that it is in the debugwire mode so I would have to cycle power before I could upload changes to the program in Dragon's ISP mode.

 

Alan

 

P.S. If what you are leading up to is uploading changes to the program before a power cycle, I could not do that since I have Avarice between Eclipse and Dragon.

 

Last Edited: Mon. Sep 11, 2017 - 11:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes,  I have used Atmel Studio(s):   AS4, AS5, AS6, AS7 with debugWIRE, JTAG, PDI, UPDI (new to AS7)

And Rowley CrossWorks for AVR with dW, JTAG, PDI.

 

No,   I have never succeeded with Eclipse for AVR. 

"Proven" Eclipse for ARM is pretty unpleasant.   I would not want to inflict Eclipse onto AVR. 

 

The debugWIRE Enable, Disable procedures must be done correctly.   But the principles are easy to understand.  i.e. when power-cycle should be avoided and when necessary.

 

Over the years I have waited patiently for someone to produce a ready-to-use AVR package.   Whether with Eclipse, NetBeans, ... or anything.

Nothing has materialised.

 

I would expect any "usable" Cross Platform IDE to be as pleasant as Rowley or AS7.   I certainly don't want to type individual gdb commands.

The AVR is almost 20 years old.    AS4 was pretty reliable 8 years ago.   IAR and Rowley have had reliable IDEs for many years.    I have always thought that a Manufacturer should enter a "licensing deal" with a commercial IDE company.    On the other hand,   the "user market" is relatively small.   I don't mind paying $100s for an IDE.    I do NOT want to pay $1000s for a licence as a hobbyist.

 

Incidentally,   it is probably cheaper to buy a dedicated Windows PC for running a free AS7 than to pay $8000 for an IAR licence (and still be tied to Windows).

 

David.

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

allano wrote:

shows that the DWEN fuse has been 'disabled' while in the debugWire mode.   So I assumed that the uC is still in the debugwire mode until power is cycled.  From what you have posted, it sounds like my assumption is true.

 

seems to indicate that the target is switched from debugwire to ISP mode in order to reprogram the DWEN fuse.  So is the uC in the ISP mode or debugwire mode before cycling power?  You seem to indicate that it is in the debugwire mode so I would have to cycle power before I could upload changes to the program in Dragon's ISP mode.

 

Alan

 

P.S. If what you are leading up to is uploading changes to the program before a power cycle, I could not do that since I have Avarice between Eclipse and Dragon.

 

I have never power cycled the  µC after a debugWIRE session. (when using AS, or Eclipse. But the ICE needs a unplug once in a while after debugging)

I exit GDB, which kills AVaRICE. Then I unprogram DWEN with AVRDUDE and use Eclipse to upload through ISP straight away.

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

Something is not right with my understanding of this. I am currently trying to confirm my understandings by entering and leaving debugWire using Atmel Studio, a Dragon and an ATmega88 sitting on an STK500.

 

I managed to start a debugWire session on my first try, but am facing the noob situation of not being able to get out of it.

 

Before starting the debugWire session I pulled the RESET strap on the STK500.

 

When, in an active debug session, I select the Debug menu and then Disable debugWIRE and Close I fail to get out of debugWire. The RESET strap on the STK500 is open.

 

 

This has worked for me before, though it's been a while..

 

Anyone spot what is wrong?

 

No, I have not un-programmed the SPIEN - at least not by any active action on my behalf.

 

Dragon firmware version 7.27 (both master and slave). Hardware version 17.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Do NOT power your target with the Dragon.   Sice you have a STK500,  I asume you are using this for power.

 

"Disable and Close" should work fine on AS7.    Do not always believe the messages.   Check whether dW is still active.

 

David.

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

Amazing.. I set up for High-Voltage programming using the STK500. When selecting Fuses in Device Programming they are read (ext, high, low) : 61, FF, 61. 

Clicking the Read button, the fuses are read again, but now... F9, FF, 61.

 

Repeated read of fuses result in varying values, eg FA, 97, FA

 

Something is really wrong.

 

Have the STK set up for High-Voltage programming, Straps VTARGET, AREF, RESET and XTAL1 all closed. OSCSEL is closed 1-2, i.e. "On-board SW Oscillator". BSEL2 is closed. Both PJUMPs are closed as per instructions in the help, i.e. PC0-PB6 and PC1-PB7.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

david.prentice wrote:
Do NOT power your target with the Dragon.   Sice you have a STK500,  I asume you are using this for power.

 

Yes.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Well, I pulled the mega328P from the Arduino Uno and got it onto the STK500 (replacing the mega88 that I've been having trouble with). This 328 has never been used in a debugWIRE situation. It has always been on it's Uno, and been used with it's bootloader and lately with ISP/AVRDUDE. Fuses never touched.

 

 

Could read fuses repeatedly without values varying.

 

But as soon as I did a Verify things went wrong. After that, repeated reads of fuses showed varying values.

 

It's just very weird.

 

Here's a sequence of repeated fuse reads:

 

FA, D7, 67

67, FF, 67

FA, FF, FA

FA, FF, 67

67, FF, 67

.

.

.

 

 

Either I'm missing something fundamental, or it looks like my STK500 has finally died on me (Notice the label "1" on RS232 CTRL? It's my first STK500, so I would say I got it about 2002-2003. A label on the back says 2001.35 with headings "År" and "Uke" which is Norwegian for "Year" and "Week". Time flies..)

 

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

My Green book says:  Mount PJUMP jumpers and mount BSEL2 terminal to PC2.

 

You appear to have a jumper on BSEL2.  And no PC2 connection.   Look at Fig 3.27.  BSEL2 Connection for ATmega8

 

Your STK500 looks very clean and shiny.   And it has a DataFlash chip mounted.   My STK500 is 20070813.

 

David.

Last Edited: Mon. Sep 11, 2017 - 08:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, it's actually not about going wrong after a verify. It's depending on the time after the STK500 was powered up. It stable readings for perhaps 20 seconds (still the weird FA, D7, FA) but then it starts varying.

 

I'm giving up for tonight..

 

EDIT: One last thing I did: The 328 is back on the Arduino Uno, and I can read fuses reliably using Studio, Dragon and ISP.

 

Something is wrong with the STK500. How I am setting it up, or it is broken.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Mon. Sep 11, 2017 - 09:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Johan

 

I just returned from the fuse calculator site http://www.engbedded.com/fusecalc/  and saw the note at the bottom of the page:

 

Note that some numerical values refer to fuses containing undefined bits (set to '1' here). Depending on the target device these fuse bits will be read either as '0' or '1'. Verification errors will occur if the values are read back with undefined bits set to '0'. Everything is fine if the values read from the device are either the same as programmed, or the following values (undefined set to '0'): Extended: 0x01

 

Does the ATmega88 have any bits in the fuses that are undefined?

 

Alan

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

Perhaps.

 

Strange thing is that ISP with the 328 on the Arduino and using the Dragon is OK, but ISP on the STK 500 and using the STK500s ISP fails.

 

There is no more fuel in my brain. I know the signs, and they say "sleep on it". Maybe tomorrow.

 

But the primary goal I have is to get AVaRICE going and I have the combo of ATmega2560 on the STK600 and using JTAG (Dragon) has passed my initial AVaRICE tests (see other thread). So I'll probably go along with that and leave all the debugWIRE problems for later.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Johan,

 

I have followed your debug journey since your 2011 thread about Avarice, 2016 debug setup attempt and your 2017 retry.  I wish I could help more but I'm using the Windows XP OS, WinAVR20100110 as a tool chain and Eclipse for an IDE when developing programs for an Atmega and ATtiny AVRs.  The ICE is a Dragon in the debugWIRE state.  Avarice (v2.9) is between avr-gdb (v 6.8 run from  inside Eclipse) and the Dragon has been transparent and trouble free (so far - knock on wood).

 

The key in that environment was to choose -g2 for Generate debugging Info and stabs+ (stabs + gdb extensions) for Debug Info Format and then set up the debug configuration a little differently than other tutorials. 

 

Alan

Last Edited: Mon. Sep 11, 2017 - 11:00 PM