Atmel ICE -- waste of money??

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

Hello everybody, after a lot of reading and researching the net, I went ahead and ordered an Atmel Ice Basic for $90 thinking it would allow me to have real debugging, single stepping, variable watch, etc. on Atmel 8-bit parts. I've used JTAG ICE in past projects on Mega1284 parts and it was pretty decent, so I was hoping for similar capability, but I'm finding the Atmel ICE with debugWire is not so great.

I spent the last 4 days trying to get somewhere with this device and it's been nothing but frustration. If there are any satisfied users out there I apologize in advance, as my post is not intended to incite. I just need to vent a little after all the time I spent to learn that the Atmel ICE is no better than a $10 Atmega Xplained Mini board in terms of debug capability. If I'm off base on any of what I'm about to say please let me know what I'm doing wrong, I'm willing to be be shown the way.

 

First off, Atmel's literature portrays the Atmel ICE as a fantastic device capable of all sorts of debugging and programming tasks. JTAG, PDI, aWire, UPDI, SWD, TPI, hardware breakpoints, software breakpoints,......whew! looks good huh? Except the debugWire system (used on the mega328P arduino) is not that great. If you're debugging a simple Blink LED program it works fine, but anything beyond that is an exercise in futility. I'll give my example to illustrate.

 

I  have an Atmega328P on an Arduino Nano board connected to a nRF24L01 wireless transceiver, a temperature/humidity sensor, some switches, LED's, and analog inputs. So I grab my new ICE and connect it to the 6-pin ISP header on the Nano and get ready to really get into the code.

 

Problem #1 : The Atmega328P uses debugWire to do debugging (Reset line) and the rest of the ISP pins for ICE programming. But the Reset line cannot have any capacitors hanging on it and any pullup resistors have to be greater than 10K ohm. So, cut traces on the Nano board to release the DTR capacitor (used for auto-programming via Arduino bootloader), and remove the 1K ohm pullup and replace with 10K ohm. Problem solved. Great, you can now use the ICE to upload code and get the chip into debugWire mode. BUT, to get into debug mode, Atmel Studio first uploads your code and then has to prompt you to enable debugWire. You have to answer OK, and then you're told you have to remove/replace power to the target, at which point debugging can begin. Note, if you want to go back to bootloader programming as in the Aruino IDE, you have to reconnect the DTR capacitor. You can get used to this cycle as a small price to pay to get real debugging right?

 

Problem #2 : Wrong! Of course, once you've entered debug mode you can't just place breakpoints anywhere you wish. Some lines just won't allow a breakpoint to be set (even with compiler Optimization turned completely off). It's rather annoying not knowing where you can place a breakpoint and where you can't. So set one or two where you can. Now try to single step through the code. Nope, can't always do it! Sometimes you can, and sometimes it jumps into assembly code (even though you pressed Step-Over, not Step-Into). Try to press Step-Out, which should take you back to where it called from, but nope, this doesn't always work either. Sometimes you try to Step-Out and the code just keeps running as if you pressed Run. The setting, single-stepping, and stepping out of code is very unpredictable at best. A lot of the time, I would set a breakpoint on some function and press Debug-Run, but the breakpoint never gets reached, or never stops there for some unknown reason. Worse yet, if you press the Stop button and try to resume debugging again, Atmel Studio will recompile and you get debugWire failure messages. This happens because you're in debugWire mode, but stopping or making a change requires a re-compile. Atmel Studio dutifully tries to upload your modified code BUT you're in debugWire enabled mode remember?, meaning SPI won't work, so can't upload and you get a different fail message. Nice, huh?  Even worse than that, you now try to Exit debugWire and Close (which is the recommended method when you're done debugging so you don't brick the chip) and find a new message telling you it couldn't exit debugWire mode. And you can't program the chip through the SPI pins either until debugWire is closed. The only way out of this is to try to use the Attach to Target button. If you're lucky it will reconnect through debugWire to the target, and then you can try again to Exit debugWire the proper way. This cycle of writing code, set breakpoints, start debug, enable debugWire mode, do your limited debugging, exit debugWire mode, make changes, re-compile, and start over again is a big PITA, and takes a couple of minutes each time.

 

Problem #3 : Okay, so maybe a lot of my complaints stem from the fact that it's an Arduino Nano, and the 328P chip only offers debugWire debug mode. But there are still a few things attributable to the Atmel ICE. Want to examine variables when the program breaks? Well, that depends on the variables. Some simple types do seem to be available to view and even modify. But I also found quite a few that said "unsupported" or "unknown identifier" and these could not be seen or added to the watch window. Most C pointers were visible though. Then there's the fact that the ICE itself could get into some infinite loop once in a while, with it's orange LED flickering away and no breakpoints hitting. The only cure was to unplug the USB cable to the ICE and try to Attach to Target again. A different issue that took me a while to catch (dumb me) was that the nRF24L01 module used the same SPI interface pins as the ICE, which led to strange crashes. I changed the nRF24L01 connections to a software SPI on different pins and the crashes went away. One other issue, in my code, I ask the user to press a reset button at a certain point when initializing the program. That's a big no-no, the debugWire interface is the Reset line, so you can't ground it through a switch to reset the chip!

 

After dealing with these quirks for a couple of days, I could almost get to the point of doing some productive debugging. However, it was now NO better than what can be done with a $10 Atmega328P Xplained Mini board. And the Xplained Mini board somehow magically handles the switching between debugWire and SPI programming seamlessly (or maybe it use the debugWire interface to upload the code?), but at any rate it dispenses with all the enable/disable pop-up windows found when using the ICE. For this chip(Atmega328P) and the debugWire method of debugging, the $90 Atmel ICE has no advantage over the $10 board. Maybe the ICE is more powerful and stable with JTAG debugging. I don't have any parts to test that out.

 

One last thing, when uploading the code to the chip after pressing Debug-Run, the Atmel ICE is very slow when flashing the chip. My program compiled to around 22 Kbytes, and it took about 50 seconds to upload. Add in the time for answering the debugWire enable prompts, and for disconnecting/reconnected power to the target, then exiting debugWire, etc. and your debug-modify cycle time is closing in on two minutes whenever you change something. Ugh....

 

Has anyone else had a GOOD experience with the Atmel ICE? I'd like to know if maybe I'm not following the right procedure, or if I'm doing something incorrectly. Or maybe the debugWire sysatem is just a POS. It's been a few years since I worked with the JTAG ICE, but I recall that went very smoothly and had hardly any of the problems that I encountered with the current Atmel ICE. Could be that JTAG offers a much better experience.

 

Thoughts or questions would be welcome. Am I expecting too much? I'd like to "like" this ICE unit, but from what I've seen so far it's not very promising.

 

-Tony

 

 

 

 

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

Long post! The problem is with the Arduino not the ice. Lots of posts about it.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

debugWire mode, but stopping or making a change requires a re-compile. Atmel Studio dutifully tries to upload your modified code BUT you're in debugWire enabled mode remember?, meaning SPI won't work, so can't upload and you get a different fail message.

It should be able to use debugwire to upload new code, without having to switch to SPI.  As you say, it does on the Xplained Mini, which essentially implements the same protocols.  Do you have the "Interface" of the tool set to "Debugwire"?

 

The use of a 1k pullup on many Nano boards is a design bug, IMO.

 

I haven't actually used the ICE to debug a 328p Arduino; it's always been more convenient to just switch to the Xplained, or go to a bigger AVR with JTAG.

 

 

For this chip(Atmega328P) and the debugWire method of debugging, the $90 Atmel ICE has no advantage over the $10 board.

Could be.  The $10 Xplained mini is quite a bargain, and debugWire certainly seems to be the bottleneck.

The big plus of the ICE is all of the other chips that it will also support, IMO.

 

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

tonyg17 wrote:
Has anyone else had a GOOD experience with the Atmel ICE?

Experience 1
I can erase, write, verify, fuse, lock, full 32kb of ATmega328P in 6 seconds with a single double click on batch file.
.
Experience 2
One time, I miswired 24v instead of 5v by mistake, Atmel-ice survived due to its protected design.
.
I have no experience on debug feature of it, I prefer traditional methods to solve semantic errors of my code:
pencil and paper,
adding "printf" "putchar" as debug to get output of desired status via UART
if UART is not available or busy, add just set/reset an available I/O port.
Maybe one day I really have to use debug wire. Not happened yet.

Majid

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

You make a good point, the Xplained Mini can do it. I did select the interface as debugWire in Atmel Studio tool page. But I forgot to mention that I have the Visual Micro plugin installed and the menu for Visual Micro has Debugger set to Atmel Studio Debugger and Uploader set to Atmel ICE.  If I try to set the uploader to mEDBG it doesn't work and the upload fails, the only option that works for upload is Atmel ICE. Maybe the problem is with Visual Micro or I'm doing something else wrong.

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

I have a whole den of Dragon's which have much the same issue.  Also have a jTag Ice MKII and a couple of the the old ICE200s. (Limited as they can only emulate a AT90s4433)

 

Most of the issues you bring up have almost nothing to do with the Debug HW.  It is GCC that hides everything.  GCC is quite clever in the illusion that there are more resources in the 328p than physically possible.

 

I tend to use a lot of global pointers and typedef memory overlays to structs.  That way everything remains in scope (providing there is physical storage.)  In theory this is what C++ does. hiding these overlays from the user.  Still one can typedef a struct of the parameters that are on the stack, Then cast this typedef to the stack pointer, and the variables (which are not in registers) can be watched.  Works alright as long as the variable is not in a register, which is usually why a value is out of scope.

 

Have not tried it, the register space is memory mapped.  So a typedef to a struct cast to the register memory map, should allow one to see the values by name, rather than register number.  Of course these are going to change, as when they are no longer needed they are overwritten.

 

Code breakpoints are another annoyance, especially when one wants to break on an index value.  I feel your annoyance too.  Yet there are good reasons why things are optimized the way they are.  It is the nature of the compiler.  Otherwise we would simply write programs in ASM or patch wires as in RPG to create micro instructions.

 

 

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

tonyg17 wrote:
But I also found quite a few that said "unsupported" or "unknown identifier" and these could not be seen or added to the watch window.

 

If its a local variable and not a volatile or global you will get this.  When I do debugging, and hit this I temporarily make the local variable volatile and this fixes the issue.

 

tonyg17 wrote:
Now try to single step through the code. Nope, can't always do it! Sometimes you can, and sometimes it jumps into assembly code (even though you pressed Step-Over, not Step-Into).

I have had this happen once in a while.

 

tonyg17 wrote:
Note, if you want to go back to bootloader programming as in the Aruino IDE, you have to reconnect the DTR capacitor. You can get used to this cycle as a small price to pay to get real debugging right?

If memory serves me correct, when eh ICE uploads your code through debugwire(yes it will do this), it erases the chip, AND the bootloader.  I could be wrong on this.

 

tonyg17 wrote:
but stopping or making a change requires a re-compile. Atmel Studio dutifully tries to upload your modified code BUT you're in debugWire enabled mode remember?, meaning SPI won't work, so can't upload and you get a different fail message. Nice, huh?

TO get the code INTO the part when in debugwire mode all you have to do is one of the following....Hit "Start debugging and break", or "Start Debugging"  Either one will re-compile your project, erase the AVR, and load your application into the AVR.

 

tonyg17 wrote:
Some lines just won't allow a breakpoint to be set (even with compiler Optimization turned completely off). It's rather annoying not knowing where you can place a breakpoint and where you can't.

I have had this problem in the past, not sure what the fix was.

 

Have I had issues with eh Atmel-ICE? Yes.  Have I had issues with Studio? Yes.   As bad as yours?  No.  As John said your hardware might be your issue.  I have been using my Atmel-ICE for several years now on many of the AVR's and a couple ARM devices and its been a pretty good experience overall. 

 

tonyg17 wrote:
Maybe the problem is with Visual Micro or I'm doing something else wrong.

Or both.  Visual Micro is a PITA and many members far more talented than I have complained loudly about it.  At the same time, some pilot error could be at play here as well. 

 

Fear not!  YOu have found the promised land by coming here.  Others will add to this post and hopefully provide you with the information you need so you won't slip on the ICE anymore(bad pun intended)

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

your debug-modify cycle time is closing in on two minutes whenever you change something.

My previous answer was using the phone and on the run. (in the middle of organizing my next holiday....wink)

 

After entering DW you need not exit it until all your debugging is done, even if it takes a year or 2. In fact it can be permanently left on if you have a board used for debug, at least until the flash wears out on the chip.

 

The BL gets erased so after the year or 2 if you want to use the same board as originally intended you will need to reload the BL and the code.

 

I have used DW since it first came out with different debugger types including the Atmel ICE, not as good or as fast as JTAG but then you don't lose 4 wires and it's only used on smaller chips.

 

As I have mostly used assembler I NEVER had the problem of not being able to place a breakpoint exactly where I want it, that's only a C "issue", if you can't place the break where you want drop down to the assembler view and see what code the compiler has produced, you can then put the break point where you want.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Items #2 and #3 have nothing to do with Atmel ICE, or with DebugWire. They are a consequence of compiler optimization. WHERE you can place a breakpoint depends on how the code was optimized. As far as variable visibility, that depends on scope, scope, and scope (and optimization). Take this, for example:

 

uint8_t TheVar = SomeFunction(x,y,z);
if (TheVar > 10) {
    do something;
}

In all likelihood, it will be "optimized" into:

 

if (SomeFunction(x,y,z) > 10) {
    do something;
}

And you will never be able to view TheVar. Sorry, thats the  way it is. Has NOTHING to do with ICE or DebugWire. You COULD have retained TheVar by declaring it volatile, but that is a different story that has been discussed several times, here.

 

Jim

 

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

 

 

Last Edited: Sat. Feb 2, 2019 - 08:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use Atmel ICE every day without what I would call serious issues. That said, its always on my own pcb's that all have a JTAG connection and, usually, a 1284P. ICE is fast and efficient and does pretty much what I expect. It was also cheaper than the AVR ONE which was a pita with a hokey debugging connector that broke all the time. I was glad when it finally crapped out for good.

My only continuing bitch with the ICE is that it loses contact with the target now and then, forcing me to restart AS7 to get it working again. Also, if I delete a breakpoint, it will act as though the breakpoint is still there until I terminate debugging.

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

You put a lot of blame on the ICE where the culprit is either the compiler, Studio or the target circuit (Arduino).

And the claim that the ICE is no better than the Xplained is true, but it doesn't mean that the ICE has no use case.

The Xplained is not designed to used with any other target than the one on board. In fact, it's specifically designed to be unusable with a different target!

The ICE however is designed to program and debug any target. So when you build your own PCBs with AVRs on them, you NEED an ICE. Hobbyists who can use an Xplained for their projects where not really the intended market for the device.

 

But to answer your original question:

My experiences with the ICE were always very good. I use it mostly with Xmega targets, which use the PDI interface. I don't have much experience with debugWire, but I used it briefly in the past and it worked well then.

I can confirm your issues with the software however.

"Some people die at 25 and aren't buried until 75." -Benjamin Franklin

 

What is life's greatest illusion?"  "Innocence, my brother." -Skyrim

 

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

Thanks everybody for the replies and suggestions. Maybe I jumped to a conclusion too quickly. It's reassuring to hear some of you have seen similar things to what I described and you have given me some good insight and ways to deal with it. I do understand a lot of the quirkiness comes from the C compiler. One thing a few of you have mentioned is that I don't need to switch between debugWire during debugging and SPI to upload. How do I get AS7 to do that? On my system it seems to want to switch to SPI for uploading and always asks me to confirm that I want to enable debugWire after the upload has completed.

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

Use "Start debug and Break"

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:

Use "Start debug and Break"

 

Which was mentioned in post #7:

jgmdesign wrote:
tonyg17 wrote: but stopping or making a change requires a re-compile. Atmel Studio dutifully tries to upload your modified code BUT you're in debugWire enabled mode remember?, meaning SPI won't work, so can't upload and you get a different fail message. Nice, huh?

 

jgmdesign wrote:

TO get the code INTO the part when in debugwire mode all you have to do is one of the following....Hit "Start debugging and break", or "Start Debugging" Either one will re-compile your project, erase the AVR, and load your application into the AVR.

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

I have used Atmel ICE with debugWire and it works fine most of the time. It is perhaps a little slow but still acceptable.

The only problem is that sometimes I have had difficulties connecting to the MCU. It is like neither dw nor ISP works. After some attempts and power cycles it works again.

/Jakob Selbing

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

westfw wrote:

For this chip(Atmega328P) and the debugWire method of debugging, the $90 Atmel ICE has no advantage over the $10 board.

Could be.  The $10 Xplained mini is quite a bargain, and debugWire certainly seems to be the bottleneck.

The big plus of the ICE is all of the other chips that it will also support, IMO.

 

If you look closely at the ATmega328P* Xplained Mini schematics you can see that the on-board debugger has control over target power. Ironically, the 10$ board can give a better user experience than the Atmel-ICE because it toggles power for you when switching between ISP/dW modes.

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

duzern wrote:

westfw wrote:

For this chip(Atmega328P) and the debugWire method of debugging, the $90 Atmel ICE has no advantage over the $10 board.

Could be.  The $10 Xplained mini is quite a bargain, and debugWire certainly seems to be the bottleneck.

The big plus of the ICE is all of the other chips that it will also support, IMO.

 

If you look closely at the ATmega328P* Xplained Mini schematics you can see that the on-board debugger has control over target power. Ironically, the 10$ board can give a better user experience than the Atmel-ICE because it toggles power for you when switching between ISP/dW modes.

Atmel-ICE _can_ do debugWIRE faster than the mEDBG... 

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

I have lots of good experience with the ICE on a Chinese Nano.  You did the right thing removing the capacitor and getting rid of the 1K resistor. I seem to remember you have to put breakpoints in ISRs before you start debugging, or they wont get hit.  You cant add them during a debug session.  That's coming from my memory, which is a little volatile.

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

That's coming from my memory, which is a little volatile.

Stay calm, don't go atomic 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

avrcandies wrote:

That's coming from my memory, which is a little volatile.

Stay calm, don't go atomic 

 

At my age my memory has turned into local variables that are erased when I exit the function....or they are optimised away.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

js wrote:
that's only a C "issue",

jgmdesign wrote:
.or they are optimised away.

Actually its a GCC issue, as its an aggressive optimizer, which is not a bad thing!

I've used other C compilers (ImageCraft, CodeVision and IAR) and have had no problems with setting break points with debugwire mpu's where I needed them.

The advice above about going into the assembler code and placing breakpoints seems a reasonable solution. 

YMMV

 

Jim

 

 

 

FF = PI > S.E.T

 

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

I cant help but think the human memory is limited in some way like a computer memory.  It cant be infinite, unless we can somehow ESP into the cloud of other people's memory space not being used.  Barring that, it would seem that to create a new memory one must lose an old one, and it seems to be a FIFO action, which is why I walk into a room and look around and wonder why I'm there.  So instead of being old (I'll be 70 this year) and senile, I can just say I have lived a rich life filled with memories, and I'm just not saving all the new ones unless they are important.  Yes, I think that pretty much covers it.cheeky

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

 

debugWire mode, but stopping or making a change requires a re-compile. Atmel Studio dutifully tries to upload your modified code BUT you're in debugWire enabled mode remember?, meaning SPI won't work, so can't upload and you get a different fail message.

 

 

My Ice just arrived today, I'm reading the datasheet and noticed this.

 

The SPI interface is effectively disabled when the debugWIRE enable fuse (DWEN) is
programmed, even if SPIEN fuse is also programmed. To re-enable the SPI interface, the
'disable debugWIRE' command must be issued while in a debugWIRE debugging session.
Disabling debugWIRE in this manner requires that the SPIEN fuse is already programmed. If
Atmel Studio fails to disable debugWIRE, it is probable because the SPIEN fuse is NOT
programmed. If this is the case, it is necessary to use a high-voltage programming interface to
program the SPIEN fuse.

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

I have run into this several times with my Dragon. Fortunately, I have never had to resort to High Voltage Programming. But, it is a bit scary at first when nothing works.

 

What has usually happened with me is the following:

 

1) Attempt to do ISP programming, but forgetting that the chip was left with debugWire enabled.

 

2) Try all sorts of ISP things, unable to even read signature.

 

3) Realize that I left it debugWire.

 

4) Go back to standard debugging mode, probably reload the existing program just to get it into the proper state.

 

5) Choose (not sure of the exact words) "Quit debugging and exit debugWire"

 

6) Proceed with ISP 

 

So far, that has worked from the state I had gotten it into.

 

Jim

 

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

 

 

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

While in debug mode to exit properly you simply go,to the debug menu drop down and select "disable debugwire and exit". This will disable disable debug wire and re enable SPI programming

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user