Unable to program fuses in DebugWire/ISP mode

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

Using the latest revision of AVR studio and the DRAGON, I can debug a program, load the program into the processor using the debugging system, but cannot set the fuses.

I get the famous "entering programming mode .... failed" message.

The parts are MEGA168 and Tiny2313, new out of the tube, more than one of them each, but on the same board.

ISP clock speed has been varied from 1.0 MHz down to 100 Hz with no difference. Clock speed can be set, board voltage is read as 4.8 volts, but anything having to do with entering programming mode fails.

I have gone right from a startup to connecting to the processor, so I'm not in debugging mode (known problem with JTAG). The JTAG interface on the Dragon works just fine.

I'm trying to avoid having to build the programming adapters for HVSP and PP modes (although the boards are now designed....)

Harvey

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

Don't you have to use ISP to set the fuses?

Leon

Leon Heller G1HSM

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

Yes, you do. The connector to the chip is the full 6 pin ISP/DebugWire connector, so the fuses are programmed in debug mode. SPI is disabled, (used for programming) and debugWire is enabled (for debugging). It's the standalone mode that allows me to set the clock frequency and such that I'm not getting to.

Harvey

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

Yeah but while in a debugging session you need to visit the debug menu which leads to a dialog in which operation can be switched back from debugwire to ISP (changing the state of the DWEN fuse which is the only one that can be changed in DW mode). Once back to ISP mode you are free to change the rest of the fuses at will.

Cliff

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

That was the problem.

Apparently, once you are in debugging mode, you stay in debugging mode unless you specifically go in and disable the debug wire fuse.

This is not how I was lead to believe that it works.

My understanding is that the part is shipped with spi enabled, dw not, you program in spi mode, then once you enter debugging mode, the fuses are swapped, dw on and spi off; once you exit debugging mode, spi is now on, and dw off.

Since the rest of the fuses are not programmable in debugwire mode, it's apparent that the above steps do not happen.

Now that I know that, the problem is solved, so there's a project (HVPP adaptor) that I don't need to build.

Thanks for that, but I'd think of this as an operational flow bug in AVR studio.

Harvey

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

Quote:
it's apparent that the above steps do not happen.
They happen for me all the time :)
Quote:
once you exit debugging mode, spi is now on, and dw off.
You HAVE to disable DW from whithin the debug session, not just a stop debug or closing the project. I was one of the "early fathers" of the Dragon and never had any problems with this.

ps from the Dragon help file:

Quote:
NOTE: When the DWEN fuse is set, the ISP Interface normal functionality is disabled. This because the debugWIRE must have control over the RESET pin. When DWEN is set it is no longer possible to use ISP. Use debugWIRE or High Voltage programming to disable the DWEN fuse.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Perhaps I was just expecting a different level of automation. If the debugging session leaves the debugWire fuse on, and SPI off, and you can leave the debugging session normally *without* enabling the SPI fuse and turning debugWire off, then that's a program design flaw to me.

I can understand if the power is turned off, or the cable unplugged, or other nasty things such as that. However, it does seem that there are occasions where the debugWire fuse is off, and the SPI fuse is also off. When I get the HV programming adapter built, I'll find out if that has happened.

I'd also think that any time the debugging mode is left gracefully (project close or stop debugging) that you'd reset the fuses for normal operation. Any idea why this was not done?

Harvey

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

Quote:
Any idea why this was not done?
NOPE! I have just been messing around with a board I haven't touched for several weeks and could not get it to program, the DW fuse is still on :oops: I had it packed with another working board so I ASS U MED that it was back to normal ISP mode :oops: perhaps there could be a checkbox to allow automatic DW disable when shutting down or stopping debug. It MAY be there with the new version???

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
Quote:
Any idea why this was not done?
NOPE! I have just been messing around with a board I havenquoted:

perhaps there could be a checkbox to allow automatic DW disable when shutting down or stopping debug. It MAY be there with the new version???

Ah, nope. Not that I have noticed. I have the latest build, and there are some problems with it. Mostly there are unplanned "crashes" every now and then, not absolutely sure what the cause is.

As far as the "graceful restore" option, AFAIK, it does not exist. It probably won't be an issue (to be corrected), until the users mass outside the castle with flambeaux and pitchforks.

Until then, I think I have to build that parallel programmer anyway. Ah well, I do have a design that needs to be put on a board, a speech synthesizer that functions as the main control processor in a 3 board handheld system....

Debugging interprocessor communications is *such* fun....

Harvey

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

great post

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

Is it possible to program the fuse bits over the debugWire interface?

I programmed the fuses on my ATTINY13 chip before putting on my board to enable debugWire. Now that it is on the board, I only have access to the two pins (reset and gnd). I can program it by opening a debugging session. But, now I want to go in and enable brown-out detection fuse bits. I have been unable to find a way to do this.

Thanks for any suggestions!
Ryan

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

Quote:
Is it possible to program the fuse bits over the debugWire interface?

Only to unprogram DWEn to get out of dW mode.

You do that on the menu while in a debug session but you will need access to all the ISP signals to then ISP program it to set the BOD

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

Maybe I am missing a bit of info here but I cannot seem to get into programming mode in AVR Studio. Probably my own fault. I have an inexpensive USB to SPI programmer board (the kit one from TuxGraphics.com) and it works great as a programmer. Just decided to try debugging with the debugWire. Like most, I cannot get it to switch back to SPI programming because SPI programming is disabled. The problem is, I cannot get AVR Studio to connect to it (ATTiny44A) using any of the debug platforms. Any suggestions?

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

But you need a debugger with DW facility (Dragon, JTAG Mk2) not a programmer.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Ya, I should have edited my post. I didn't catch on to that until a bit after posting it. Now I know.

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

I am having a similar problem with some 32A ATmega168 chips on a custom board with an ISP connector, Studio 4.18/684, and an avrispII.

In Studio I connect to a new chip using the avrispII and SPI, switch to DW, do some debugging, and that all seems to work ok. I do not switch back to ISP before exiting Studio and powering down. The next time I power up the board, Studio brings up a dialog 'Unable to connect to device' and offers to retry the DW connection. The dialog includes the option to use SPI but of course SPIEN has been cleared to enable DW. Retries are ineffective.

The reset line is connected to nothing but the SPI connector.

Why has DW stopped working? Is there some way to re-enable SPI from Studio? I am talking about a 32A device, so I cannot drop it into an STK500 for a HV reset.

Regards
ronkrem

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

Quote:

I am talking about a 32A device, so I cannot drop it into an STK500 for a HV reset.

Err why? 32A is just a die-shrink 32 but in every other sense (including programming) you just treat it like a 32 and the STK500 has no issues with programming a 32.

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

Quote:
32A is just a die-shrink 32
I think he means a 32 pin ATmega168.
Quote:
switch to DW, do some debugging,
But what are you using for debugging?? The avrispII CANNOT do debugging, how in the world are you doing your debug??

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I had isp on the brain. I meant jtagice2. And yes, it is the 32 pin flat pack version, already soldered into the custom boards.

Ronkrem

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

I had isp on the brain. I meant jtagice2. And yes, it is the 32 pin flat pack version, already soldered into the custom boards.

Ronkrem

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

Ok so I always do just a "build and run" and never specifically change the DW fuse, which of course gets programmed the 1st time around in the debug session.

Are you turning on JTAG before the target? Also I always have a 4K7 pullup resistor without issues. May want to try that even if it is the recomended 10K minimum.

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

I had done the opposite and went for a 27K reset pullup. Scoping the reset line showed it never going high. I tried your 4.7K and it certainly pulls it up but still no go on entering debug or, of course, returning to spi.

What is intiguing in this case is I switched the first '168 to DW over a month ago and have been debugging up to now with no hitch. A couple of days ago this happened. At first I thought the chip had failed, so I replaced it, reconnected via spi, switched it to DW and again the connection failed. The same happened when I assembled a complete new board.

Getting paranoid now I suspected my jtagice2 so I connected it to another project which used a jtag interface and debugging was fine.

Your advise of letting Studio do the switching might be the go. If nobody knows why the DW has failed then these boards are spare parts. Perhaps I'll try patching in enough wires to do a HV reset via the stk500.

Cheers
Ron

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

Quote:
I connected it to another project which used a jtag interface and debugging was fine.
But DW uses different lines, so it may not prove anything. My JTAG died a few weeks ago and the TVS chip right behind the JTAG lead connector had done it's job shorting one of the pins (the one used for DW and ISP).

Try ISP, if that doesn't work then you may have a zapped chip in the JTAG.

edit link added https://www.avrfreaks.net/index.p...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Looks like that's it. Good thing Farnell have got them for about $60.
Cheers

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

Quote:
Farnell have got them for about $60.
What? The chip is not that expensive. :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Sorry, $5. I have ordered a couple. It (the SP720ABG) checked ok in situ and with it removed I still had the same problem (no DW access and no way back to spi). I followed the other threads but could not find my answer. Do you think it is one of the MAX chips? I would really like a circuit diagram.

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

Quote:
Do you think it is one of the MAX chips?
Could be. But no diagram unfortunately, so it's the old hunting game with the multimeter.

Michael had one of the MAX chips dead.

edit and of course I would test the flex cable too on the reset line, see if it makes it back to the PCB from the header.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Hi All

I am revisiting this subject because the July/August issue of Elektor showed a "Reanimating Probe for AVR uC" on page 69. I still have a number of boards with soldered in "not responding" 328Ps that are just junk unless they can be resurrected. Has anyone tried this little gizmo? Would it work? www.elektor.com/110374

Cheers
ronkrem

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

Quote:

Would it work?

Read this:

Recovering from a "locked out" AVR

As long as it's not RSTDISBL that's been activated then, yes, this should work - just as any "injected clock" will work - but obviously make sure ISP is set to 1/4 or less of the clock frequency.

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

Interesting to see that in 2018 this issue still exist.

I have switched successfully from SPI to DW mode and been using the latter for several weeks.

Now I need to set the SPM fuse so in Atmel studio (version 7) I used "Debug->Disable Debug wire and close".

But I still can't use the SPI interface. (Tools->Device-proramming, interface ISP, Apply, 125Kz, set, fuses => Failed to enter programming mode )

Debugging after that fails but it can enable the debug wire mode again ("toggle power and press OK" then debugging works again)

I also tried removing the power after using "Debug->Disable Debug wire and close" to no avail.

 

I did use SPI successfully when I started the project, so my programmer (SAM-ICE) and connections are OK.

 

It seems I have to buy and use a new chip each time I need different fuse settings.

Make sure all the fuses are in the right state, switch to debug wire mode and throw it

away when I need different fuses.

 

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

Of course not.

 

1.  create a new project with debugWIRE as "connected debugger tool".   e.g. with trivial main() function.

2.  select "Start Debugging and Break"

3.  it loads and stops at your main()

4.  select "disable debugWIRE and Close"

 

You can skip (1) and just "debug" an existing project.   A small project "starts" quicker.

 

SAM-ICE looks like a badged JLink.    I suspect that it only does JTAG/SWD

 

ATMEL-ICE handles debugWIRE, PDI, JTAG, SWD, ...

 

Daid.

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

David,

thank you.

 

To begin with: that is what I did, start the debug session and when it hit a

break point I used "disable debugWIRE and Close"

 

As you were adamant that it is suppose to work I tried again but still failed.

In the end I decided to put my scope probes on the SPI pins and after that it worked.

Took the scope probes off again (To eliminate capacitive loading and reflections)

It still worked.

 

I have now tried two times to switch between ISP and debug wire and it works both times.

So the most likely scenario is that I had a dodgy SPI connection.

 

Thank you!

I can now continue to work out why FLASH erasure works for me but

programming only puts different garbage in the sector each time I try.