Why 'Disable debugWIRE and Close' after a debug session ?

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

Just got my newly arrived Xplained board and aeger to learn Debugging the proper way.

Soon got into trouble  after my first debug attempt.

Once I 'Stop Debugging' I could no longer re-program the ATmega328P from the Xplained board.

I was getting an error message:

A quick search on this Forum lead me to This Comment proposing to click 'Disable debugWIRE and Close'.

It worked perfectly. I am now able to re-upload a new version of my program.

So, I am wondering if this is a bug of Studio7 or Xplained board or if this is a normal behavior ?

Why would Studio7 still offer to simply 'Stop Debugging' if it is surely lead to a subsequent error on the next programming attempt. 

What would be the benefit of such behavior from the system ?

Am I doing the steps correctly ? Is there another way of going from Debugging to Programming so that this error doesn't happen ?

( Some reading suggestions welcome )

This topic has a solution.
Last Edited: Tue. Jan 25, 2022 - 09:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it's your recommended behavior, more people will be in trouble.
> The target power must be turned off and then on again after each debug run.
> Cannot attach with the debugger while retaining the buggy state on the device.

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

Thanks for your quick reply,

Just a little more details pls. When, exactly, should the power be turned OFF ?

I go OFF while in debug mode ? or after 'Stop Debugging' is selected ?

 

And what do you mean by 

kabasan wrote:
Cannot attach with the debugger while retaining the buggy state on the device.

 

By the way

kabasan wrote:
If it's your recommended behavior, more people will be in trouble.

I am not pretending to recommend anything, I was just presenting what I did to get out of the error. Just saying.

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

You'll find, the hard way that if you don't do a 'Disable debugWIRE and Close' you'll BRICK the device.  Makes a decent doorstop though!

 

When you debug it sets a fuse and when you 'Disable debugWIRE and Close' it resets the fuse.

Happy Trails,

Mike

JaxCoder.com => PartsBin - An Electronics Component Organizer

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

When debugging and you want to stop (and leave chip in non DWEN state) use the option on the debug menu and do what the messages tell you EXACTLY. 

 

But given that debugging starts by it downloading the code anyway do you even need to switch it out of DWEN mode anyway?

 

When you trade up to larger AVR (40 pin or more) they have more sensible and easier to operate debug interfaces (principally JTAG) so you don't have to play the debugWire song and dance all the time 

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

General rules:

 

1.  follow AS7.0 advice exactly for enabling debugWIRE.   i.e. remove power when it tells you.

 

2.  just use Debug->Start Debugging and Break.   and  Debug->Stop Debugging during development.

 

3.  when your project has finished or you go on holiday,  remember to Debug->Disable and Close.

 

(3) is wise if your memory is not very good.  Especially if you can't remember what you had for Breakfast.

 

David.

Last Edited: Fri. Dec 24, 2021 - 05:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


clawson wrote:
do you even need to switch it out of DWEN mode anyway?

No, you don't.

 

You can leave it in debug mode - only switch out of DWEN when you have a specific reason to do so; eg, you've finished developing, or you want to test low-power modes.

 

FredCailloux wrote:

I was getting an error message:

 

 

You're trying to program via ISP when the chip is in debugWIRE mode (DWEN).

 

The chip can be programmed either via ISP or via debugWIRE.

 

While you're in the download - debug - fix code - download again - debug some more cycle, leave it in debugWIRE mode.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FredCailloux wrote:
When, exactly, should the power be turned OFF ?

Microchip Studio tells you when the target needs to be power-cycled - be sure to read the messages carefully, and follow the instructions precisely.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Debug Wire State Diagram may help with your understandingDebugWire state diagram

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

My strategy is to do the following:

 

1. When a chip is new or has been ISP programmed, and a new development session is begun, enable DebugWire.

 

2. During development, even though debug is closed, leave DebugWire enabled.

 

3. ONLY when you need to go back to ISP programming, do "Disable DebugWire and Close"

 

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The DW mode uses the reset pin for it's comm with the OCD inside the chip, so once it's enabled, the pin is no longer the reset pin!

Since ISP programming requires reset, it can't happen while in debug mode! 

If you forget your chip is in debug mode, and you later try and fail at ISP programming, just enter a debug session and then exit properly, now the ISP will work again, and no, the chip is not bricked!

It will become second nature to you after a short time, enjoy your debug sessions!

Happy New Year!

Jim

 

 

FF = PI > S.E.T

 

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

ka7ehk wrote:
My strategy is to do the following

 

Exactly, I am doing the same with JTAGICE mkII.

No need to terminate DW, in some projects may remain forever.

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

ki0bk wrote:
If you forget your chip is in debug mode, and you later try and fail at ISP programming, just enter a debug session and then exit properly,

IIRC, Microchip Studio will actually prompt you to do that ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...