Debugwire and High voltage programming

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

I'm planning for a device with the ATmega64M1. To ease software development I'd like to be able to use Debugwire for debugging. As I understand it this requires programming the DWEN fuse, which disables the RESET function of the reset pin. This in turn removes the ability to use ISP as the reset function is gone. The only programming ability left is a kind of high voltage programming.

Am I correct with my understanding ?

In the case of the ATmega64M1, the only high voltage programming method seems to be parallel programming, is my reading of the datasheet correct ?

Parallel programming on the ATmega64M1 seems to need 18 pins, imposing severe constraints on the circuit. If using Debugwire requires resorting to debugwire, as it looks like to me, the I find this a severe restriction. In my case I think this makes Debugwire useless to me.

Markus

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

Quote:

As I understand it this requires programming the DWEN fuse, which disables the RESET function of the reset pin.

Not quite. You do start by using ISP to change the state of DWEN but the _RESET pin retains it's usual functionality. To get back from dW mode all you do is (a) make sure all 6 ISP wires are in place and (b) start a debug session then use the bottom entry on the Debug menu. In that dialog is an option to "switch back from DWEN to SPIEN" (in effect). You use use that and you are back to ISP.

Yes the HV is parallel and requires about 20 signals (inpractical in most designs with the chip in circuit) but you shouldn't ever need to use it.

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

Excellent !

So the debugwire protocol can program fuses back and re-enable ISP programming, then. All I need to have my normal ISP header and I'm all set, then.

Does this apply for all Debugwire AVR's ?

I'm working on tiny85 currently where I have ISP, but due to the same reflections I have not tried to use debugwire. As I did not have all pins for (serial) high level programming. Some printfs with a software-UART are my main debug tool there now.

Markus

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

Quote:

All I need to have my normal ISP header and I'm all set, then.

Does this apply for all Debugwire AVR's ?


Yes and yes.

Note: There have been sporadic reports here of dW chips supposedly stuck "between dW and ISP mode" and only recoverable by HV but little concrete evidence.

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

Yes I've heard that dW seems to get into trouble. We'll see.

Thanks !

One problem down, more to go !

Markus

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

I reckon that debugWire works very well. You just need to have a sound policy for entering / leaving dW. e.g. always leave dW before you dismantle a board.

Most of the dW horror stories are apochryphal. It would be nice to have a documented chain of events. And the result of a subsequent fuse reading by HVSP/HVPP.

David.

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

I reckon that debugWire works very well. You just need to have a sound policy for entering / leaving dW. e.g. always leave dW before you dismantle a board / change project.

Most of the dW horror stories are apochryphal. It would be nice to have a documented chain of events. And the result of a subsequent fuse reading by HVSP/HVPP.

David.

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

I started to play, but have not gotten very far. I'm on Linux, so my tools are avrdude and avarice. Both have provisions for setting/clearing fuses, both can do dW.

My testcase is a tiny85, DWEN is bit6 in hfuse. It reads currently as DF, so I have to change it to 9F to enable dW and put it back to DF afterwards to enable ISP again.

Entering dW with avrdude works fine:

markus@T60:~$ avrdude -P usb -c dragon_isp -p t85 -v -U hfuse:w:0x9F:m

avrdude: Version 5.10, compiled on Jun 30 2010 at 20:31:41
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/usr/local/avr/etc/avrdude.conf"
         User configuration file is "/home/markus/.avrduderc"

         Using Port                    : usb
         Using Programmer              : dragon_isp
avrdude: usbdev_open(): Found AVRDRAGON, serno: 00A2000053CF
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
  boot-loader FW version:        255
  firmware version:              1.01
  hardware version:              1
S_MCU:
  boot-loader FW version:        255
  firmware version:              2.00
  hardware version:              6
Serial number:                   00:a2:00:00:53:cf
Device ID:                       AVRDRAGON
         AVR Part                      : ATtiny85
         Chip Erase delay              : 4500 us
         PAGEL                         : P00
         BS2                           : P00
         RESET disposition             : possible i/o
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65     6     4    0 no        512    4      0  4000  4500 0xff 0xff
           flash         65     6    32    0 yes      8192   64    128  4500  4500 0xff 0xff
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           calibration    0     0     0    0 no          2    0      0     0     0 0x00 0x00

         Programmer Type : DRAGON_ISP
         Description     : Atmel AVR Dragon in ISP mode
         Vtarget         : 5.0 V
         SCK period      : 4.00 us

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e930b
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: reading input file "0x9F"
avrdude: writing hfuse (1 bytes):

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

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0x9F:
avrdude: load data hfuse data from input file 0x9F:
avrdude: input file 0x9F contains 1 bytes
avrdude: reading on-chip hfuse data:

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

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified

avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as 9F
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

But I can not get it out of dW anymore:

markus@T60:~$ avrdude -P usb -c dragon_dw -p t85 -v -U hfuse:w:0xDF:m

avrdude: Version 5.10, compiled on Jun 30 2010 at 20:31:41
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/usr/local/avr/etc/avrdude.conf"
         User configuration file is "/home/markus/.avrduderc"

         Using Port                    : usb
         Using Programmer              : dragon_dw
avrdude: usbdev_open(): Found AVRDRAGON, serno: 00A2000053CF
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
  boot-loader FW version:        255
  firmware version:              1.01
  hardware version:              1
S_MCU:
  boot-loader FW version:        255
  firmware version:              2.00
  hardware version:              6
Serial number:                   00:a2:00:00:53:cf
Device ID:                       AVRDRAGON
avrdude: jtagmkII_setparm(): bad response to set parameter command: RSP_DEBUGWIRE_SYNC_FAILED
avrdude: jtagmkII_close(): timeout/error communicating with programmer (status -1)
avrdude: jtagmkII_close(): timeout/error communicating with programmer (status -1)

avrdude done.  Thank you.

It looks like avarice is not working either:

markus@T60:~$ sudo /usr/local/avr/bin/avarice --dragon --debugwire --read-fuses
AVaRICE version 2.10, Jun 30 2010 20:31:30

JTAG config starting.
Failed to synchronise with the JTAG ICE (is it connected and powered?)

markus@T60:~$ sudo /usr/local/avr/bin/avarice --dragon --debugwire --read-fuses -d
AVaRICE version 2.10, Jun 30 2010 20:31:30

Found JTAG ICE, serno: 00A2000053CF
JTAG config starting.
Attempting synchronisation at bitrate 19200

command[0x01, 1]: 01 
recv: timeout

command[0x01, 2]: 01 
recv: timeout

command[0x01, 3]: 01 
recv: 0x1b
recv: 0x01
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  ac
recv: 0xa3
recv: 0x68
CRC OK
Got message seqno 1 (command_sequence == 0)

got wrong sequence number, 1 != 0
recv: timeout
Attempting synchronisation at bitrate 115200
(removed many other synchronisation attempts)

My plan is to use this sequence:
Enter dW:

avrdude -P usb -c dragon_isp -p t85 -v -U hfuse:w:0x9F

Perform my development (programming/debuging) with avarice.

avarice -g -w -e -p  :4242

Exit dW:

avrdude -P usb -c dragon_dw -p t85 -v -U hfuse:w:0xDF

Markus

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

No. I have no experience of dW under linux.

It works very well with C-Spy or Studio under Windows.
You let the debugger control the enter / leave dW.

You can also use the command-line jtagicemkii.exe or avrdragonice.exe to exit dW with the -W switch.

AFIK, avrdude is not capable of doing a '-W' operation.

David.

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

avrdude has 'dragon_dw = Atmel AVR Dragon in debugWire mode', this sounds very much like debugWire to me.

Also, if avrdude does not work, avarice should be able to do the trick too. I can do debugWire and can write fuse bytes. I suspect I have a very basic problem with it.

Markus

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

DebugWire cannot write fuse bytes AFIK.

Yes. I have used 'avrdude -c dragon_dw' under Windows o upload firmware. I am not aware of any -W switch to leave dW mode.

If you have managed to change fuses in dW mode, I can only assume that you had the ISP lines still connected.

Personally, I would get to know avrice with JTAG first. It is a lot more forgiving. If you can manage to debug with JTAG comfortably, progress to dW.

I have asked on several occasions about people's experience of debugging under Linux.

It appears that some users simply emulate Windows and run Studio. Others may do the odd 'db' command from a command line, but never a realistic debugging session.

I would love to hear from someone who can have a session similar to Studio or Rowley. I am not a lover of GUIs, but when it comes to debugging I am sold.

David.

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

Quote:
Note: There have been sporadic reports here of dW chips supposedly stuck "between dW and ISP mode" and only recoverable by HV but little concrete evidence.

Unfortunately, the evidence is in the pile of chips that are unrecoverable without HV mode. Since DW came out, I estimate that 20-30 chips in my designs have fallen prey to this hidden trap between ISP-DW-ISP. The factory has confirmed that the trap exists, but they cannot explain the mechanism for getting there. Best explaination so for is a negative voltage spike on VCC during power up.

My best advice to the OP is this: Use a seperate power switch to supply power to the target. DON'T use the power switch on your power supply to apply and remove power to the target. Although it seems unlikey that a negative voltage would appear when using the PS switch, the PS voltage output could climb slowly, or become non-monotonic during power-up which could cause the AVR to "freak out" at a bad momemt.

Although there are many users who have not seen this at all, there are many users like myself who seems to have been cursed by this effect. The instances of this happening have dropped (maybe even gone away), since I started using a seperate switch for target power. Maybe I just have weird power supplies.

While I'm on the soapbox, I would like to express my opinion once again about HV mode. IMHO, there should not be a parallel HV mode. IT SHOULD ALWAYS BE SERIAL (PERIOD). I don't care how many pins the device has. That's completely irrelevant. The device should always be recoverable with the standard ISP connections - No extra line should be needed. A high voltage on the Reset line, and maybe a special unlock sequence, should be all that's necessary to enter HV mode. This would allow device recovery while the device is mounted to any target board with an ISP interface. This seems entirely logical to me. HV parallel mode while mounted to a target board is pretty much useless.

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

gahelton,

So when you connect one of these "locked" chips up to HVPP what has actually happened? Is it that neither DWEN nor SPIEN is set or something? That's the thing that I know both DP and I are very interested to hear.

Cliff

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

Quote:
The device should always be recoverable with the standard ISP connections - No extra line should be needed. A high voltage on the Reset line, and maybe a special unlock sequence, should be all that's necessary to enter HV mode.

This is how PIC16Fxxx and PIC18Fxxxx devices operate. And the PicKit2 works a treat.

When AVRs first started, a lot of the competitor chips were parallel programmed or OTP. Nowadays, most chips are more convenient to use.

David.

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

Clawson wrote:

Quote:
So when you connect one of these "locked" chips up to HVPP what has actually happened? Is it that neither DWEN nor SPIEN is set or something? That's the thing that I know both DP and I are very interested to hear.

Sorry Clawson. I never actually recovered one using HV mode, although I always assumed that it could be done. All of my designs use the MLF32 package, and I just wasn't going to go through the trouble of hooking up all those lines. Instead, I gave a several chips that were in this hung state to an Atmel FAE, and he sent them back to the factory for analysis. It is my believe that there is another fuse (hidden EEPROM bit) that is used to help transistion back and forth. I don't think it's as simple as the DW fuse only. I don't have any direct evidence to support that - just a gut feeling based on the behavior of AVR Studio during the transitions. In almost every instance where the device has become hung, AVR Studio first reports the DW mode has been entered, and that target power should be cycled, but after power is cycled, Studio cannot communicate to the target through DW or ISP. At this point, no amount of reseting and retrying will work. The most critical time, it appears, is transitioning from ISP to DW. Although there may have been an instance where the device failed from DW to ISP, it's not nearly as common.

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

gahelton wrote:
Unfortunately, the evidence is in the pile of chips that are unrecoverable without HV mode. Since DW came out, I estimate that 20-30 chips in my designs have fallen prey to this hidden trap between ISP-DW-ISP.

I have the tiny85 and its power supply (5V LDO) on the same PCB, there is no power switch.

Quote:
While I'm on the soapbox, I would like to express my opinion once again about HV mode. IMHO, there should not be a parallel HV mode. IT SHOULD ALWAYS BE SERIAL (PERIOD). I don't care how many pins the device has. That's completely irrelevant. The device should always be recoverable with the standard ISP connections - No extra line should be needed. A high voltage on the Reset line, and maybe a special unlock sequence, should be all that's necessary to enter HV mode. This would allow device recovery while the device is mounted to any target board with an ISP interface. This seems entirely logical to me. HV parallel mode while mounted to a target board is pretty much useless.

I completely agree with you here, on the tiny 85 I'm working with here, HV serial programming needs one pin more then ISP, I do not see much reason other that clueless engineers at Atmel.

My other example the Mega64M1, only supports HV parallel programming. This chip is only available in TQFP or QFN packages and is generally soldered on the target PCB. HV parallel programming needs 18 pins, this is more that half of all I/O pins of the device, making parallel programming a complete illusion. What were the Atmel engineers smoking ?

All of this seems to indicate that dW is not very practical in many applications because you need HV programming to get out of it.

Markus

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

Quote:

Instead, I gave a several chips that were in this hung state to an Atmel FAE, and he sent them back to the factory for analysis.

Then don't go with "gut feelings". Demand to hear the outcome of their analysis. As I say we've seen sporadic reports of this "stuck between ISP and dW" thing here (mainly 48/88/168 in fact - but maybe just because they are the most used dW chips?) yet, when pressed for someone to do HVPP and determine exactly what has happened no one has ever done this. I'm not suggesting you are lying or anything like that - it's simply infuriating to read repeated reports of something that's never been fully investigated to conclusion. If what's actually happened were known then theories of how it got there could be tested and the mechanism by which it occurs established so that others could then be warned against it.

As you say it's got to be something procedural where some people's use of the chips is different to others and in one particular procedure there is some potential pitfall.

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

Both the factory analysis and my "gut" feelings were given. The factory analysis was inconclusive. Their best guess was a negative voltage spike on VCC. But once again, they did not know for certain. I'll see if I can find the email report, but after a couple of years, it's probably gone by now.

None of my designs use a DIP device, and I don't have a MLF32 to DIP adapter right now, so it's not practical for me to try to rescue or analyze a hung device in this package right now. However, at least a couple of times a year, I will order some sort of adapter from one of the cheap protoytpe PCB houses. A MLF32 (solder down) to DIP adapter will be included in the next batch of boards. Maybe this will give some greater insite into this problem - maybe not.

There have been enough reported instances of this occuring to believe that something is going on - rare as it may be. I cannot recall an instance of this occuring when a seperate power switch was used to apply/remove target power (not the power switch on the power supply). That's the best suggestion that I can give right now.

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

I've been able to recover my tiny85 into a known-good ISP state. This by installing Studio 4 into a virtual machine and entering/leaving debug mode. I had the impression that the chip was not really in dW mode first as I had to 'enter dW mode' when starting the debugger.

For now it looks to me like debugging with dW under Linux is not only not working, but attempting it you get you chip into a state where you need Studio to reset it to normal.

Markus

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

markus_b wrote:
For now it looks to me like debugging with dW under Linux is not only not working, but attempting it you get you chip into a state where you need Studio to reset it to normal.
The partially annotated transaction log below shows the interchange between AVR Studio and a JTAGICE MkII when I turn off debugWire on a tiny167. This may be useful for writing a simple utility on Linus to disable debugWire (or, possbily, to modify avrdude to have that capability). The Atmel application AVR067 documents the JTAGICE mkII communication protocol.

I suspect that the "reset with DW disabled" command is an important step in preparing the disable the DWEN fuse. Note, particularly, that a series of "low level SPI" commands are used to read and program fuses. It's been a while since I looked at how avrdude communicates with a programmer so I don't remember if avrdude uses the low level SPI commands.

Cmd: Read Emulator Parameter 0
 1B 27 00 03 00 00 00 0E 02 03 00 75 10            .'.........u.   

Reply: RSP_OK (0x80)
 1B 27 00 01 00 00 00 0E 80 8C 28                  .'......€Œ(     

Cmd: Reset (with debugWire disable)
 1B 28 00 02 00 00 00 0E 0B 04 4A 5E               .(........J^    

Reply: RSP_OK (0x80)
 1B 28 00 01 00 00 00 0E 80 3E 99                  .(......€>™     

Cmd: Set Parameter (emulator mode = SPI)
 1B 29 00 03 00 00 00 0E 02 03 03 15 A3            .)..........£   

Reply: RSP_OK (0x80)
 1B 29 00 01 00 00 00 0E 80 81 18                  .)......€.     

Cmd: Universal SPI Cmd (read signature byte 0)
 1B 2A 00 05 00 00 00 0E 1D 30 00 00 00 63 4B      .*.......0...cK 

Reply: RSP_RSP_SPI_DATA (0x1e)
 1B 2A 00 02 00 00 00 0E 88 1E CF DC               .*......ˆ.ÏÜ    

Cmd: Universal SPI Cmd read signature byte 1)
 1B 2B 00 05 00 00 00 0E 1D 30 00 01 00 EE D7      .+.......0...î× 

Reply: RSP_RSP_SPI_DATA (0x94)
 1B 2B 00 02 00 00 00 0E 88 94 60 BA               .+......ˆ”`º    

Cmd: Universal SPI Cmd (read signature byte 2)
 1B 2C 00 05 00 00 00 0E 1D 30 00 02 00 1E 7F      .,.......0.... 

Reply: RSP_RSP_SPI_DATA (0x87)
 1B 2C 00 02 00 00 00 0E 88 87 98 71               .,......ˆ‡˜q    

Cmd: Universal SPI Cmd (read fuse high bits)
 1B 2D 00 05 00 00 00 0E 1D 58 08 00 00 05 73      .-.......X....s 

Reply: RSP_RSP_SPI_DATA (0x95)
 1B 2D 00 02 00 00 00 0E 88 95 F6 0F               .-......ˆ•ö.    

Cmd: Universal SPI Cmd (write fuse high bits = 0xd5)
 1B 2E 00 05 00 00 00 0E 1D AC A8 00 D5 DB 7F      .........¬¨.ÕÛ 

Reply: RSP_RSP_SPI_DATA (0x88)
 1B 2E 00 02 00 00 00 0E 88 00 D5 1A               ........ˆ.Õ.    

Cmd: Universal SPI Cmd (read fuse high bits)
 1B 2F 00 05 00 00 00 0E 1D 58 08 00 00 BE 71      ./.......X...¾q 

Reply: RSP_RSP_SPI_DATA (0xd5)
 1B 2F 00 02 00 00 00 0E 88 D5 08 D6               ./......ˆÕ.Ö    

Cmd: Command Forced Stop
 1B 30 00 02 00 00 00 0E 0A 01 61 90               .0........a    

Reply: Operation cannot be performed (0xa4)
 1B 30 00 01 00 00 00 0E A4 DC 88                  .0......¤Üˆ     

Cmd: Restore Target
 1B 31 00 01 00 00 00 0E 23 D4 F9                  .1......#Ôù     

Reply: RSP_OK (0x80)
 1B 31 00 01 00 00 00 0E 80 45 6E                  .1......€En     

Cmd: Reset (low level)
 1B 32 00 02 00 00 00 0E 0B 01 43 12               .2........C.    

Reply: Operation cannot be performed (0xa4)
 1B 32 00 01 00 00 00 0E A4 B3 83                  .2......¤³ƒ     

Cmd: Start Program Execution
 1B 33 00 01 00 00 00 0E 08 6A 6D                  .3.......jm     

Reply: Operation cannot be performed (0xa4)
 1B 33 00 01 00 00 00 0E A4 0C 02                  .3......¤..     

Cmd: Sign Off
 1B 34 00 01 00 00 00 0E 00 2C 7D                  .4.......,}     

Reply: RSP_OK (0x80)
 1B 34 00 01 00 00 00 0E 80 24 F9                  .4......€$ù

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net