fuses?

[plasticassius]

Dave, this tool is already very useful. Do you think it's possible there's a way to use debug wire to change fuses? If so, after initially enabling debug wire, it would be possible to completely put away the whole rest of the suite of programmers (SPI, HVP, USB).

[dcwbrown]

I cannot see any way to do so, and all references I've found, official and comments in mailing lists, say it is not possible to do so. DebugWire works by executing normal instructions. It can access exactly what the normal instruction set can access. It would be quite easy for dwdebug to read the fuses and lock bits by using the RFLB flag in SPMCSR, but there's no way to write the fuses. Only high voltage programming mode provides guaranteed write access to the fuses. SPI mode also works, but only if it is enabled in the fuses. Sadly. Unless - do you know of any way to write the fuses from running code?

-- Dave.

On 2017-02-18 23:02, plasticassius wrote: Dave, this tool is already very useful. Do you think it's possible there's a way to use debug wire to change fuses? If so, after initially enabling debug wire, it would be possible to completely put away the whole rest of the suite of programmers (SPI, HVP, USB). -- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

Links: ------ [1] #20 [2] https://github.com/notifications/unsubscribe-auth/ADChoLK_-KZq0PjXzvhZAez2jfUlz5FCks5rd3hogaJpZM4MFSeW

[plasticassius]

I just hoped you knew about some undocumented thing DebugWire could do, but I don't have any insight into this. I guess we still need to pull out the other programmers for fuses.

[dcwbrown]

I bought one of those very cheap attiny usb boards you mentioned earlier but I haven't played with it. I wonder whether one could solder a stack of diodes and capacitors to make a charge pump and have enough pins to implement high voltage programming mode.

On 2017-02-19 14:29, plasticassius wrote: I just hoped you knew about some undocumented thing DebugWire could do, but I don't have any insight into this. I guess we still need to pull out the other programmers for fuses. -- You are receiving this because you commented. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

Links: ------ [1] #20 (comment) [2] https://github.com/notifications/unsubscribe-auth/ADChoDHVShvs2pwm196tNrNEaxR-mY1Xks5reFHmgaJpZM4MFSeW

[plasticassius]

It's quite possible, but my opinion is that it's not worth the trouble when you can order something like this or this. It's just a matter of waiting the couple of weeks for the shipment.

I can send you code I've adapted from here for an attiny13 if you're interested.

[dcwbrown]

Yes, these little power converters are a modern marvel. That arduinodiy link looks good. I guess that's the simplest solution.

[plasticassius]

Here's my adaptation in case it comes in handy:

#if 0 // MAKEFILE{

MCU = attiny13
F_CPU = 9600000

#endif // MAKEFILE}

#include "arduino.hpp"
#include <util/delay.h>

// AVR High-voltage Serial Fuse Reprogrammer
// Adapted from code and design by Paul Willoughby 03/20/2010
// http://www.rickety.us/2010/03/arduino-avr-high-voltage-serial-programmer/
// Fuse Calc:
//   http://www.engbedded.com/fusecalc/
//https://arduinodiy.wordpress.com/2015/05/16/high-voltage-programmingunbricking-for-attiny/

// definitions for the controller
#define VCC 2 // Target VCC
#define RST 4 // Output to level shifter
#define SCI 3 // Target Clock Input
#define SDO 1 // Target Data Output
#define SII 5 // Target Instruction Input
#define SDI 0 // Target Data Input

/*
_______
| NPN |
|BC337|
--|||--
  CBE

     R 1K
V+12--zz--o--->RST
          |
        | /C
       B|/
RST>----|\
        | >E
      Q   |
   BC337  |
         GND

   3D
___|___
| BSS |
| 138 |
-|---|-
 1G  2S

     R 2K2
V+12--zz--o--->RST
          |
      G |-- D
RST>--->|<-
  Q     |-| S
  BSS138  |
         GND

     R 1K  /
VCC>--zz--|<--<V+5

# Attiny25, Attiny45, Attiny85 & Attiny13
# 1 PB5 RST
# 2 PB3 SCI
# 3 PB4
# 4 GND
# 5 PB0 SDI
# 6 PB1 SII
# 7 PB2 SDO
# 8 VCC

# Attiny24, Attiny44, Attiny84
# 01 VCC
# 02 PB0 SCI
# 03 PB1
# 04 PB3 RST
# 05 PB2
# 06 PA7
# 07 PA6 SDI
# 08 PA5 SII
# 09 PA4 SDO
# 10 PA3
# 11 PA2 GND
# 12 PA1 GND
# 13 PA0 GND
# 14 GND

# HV____ X4____ X5___ nRF24L01+
#  1 GND 14 GND 4 GND 1 GND
#  2 VCC 01 VCC 8 VCC 2 VCC
#  3 GND 11 PA2       3 CE
#  4 GND 13 PA0       4 CS
#  5 SDO 09 PA4 7 PB2 5 SCK
#  6 SII 08 PA5 6 PB1 6 MOSI
#  7 SDI 07 PA6 5 PB0 7 MISO
#  8 SCI 02 PB0 2 PB3 8 IRQ
#  9 GND 12 PA1
# 10 RST 04 PB3 1 PB5

*/

#define HFUSE  0x747C
#define LFUSE  0x646C
#define EFUSE  0x666E

// Define ATTiny series signatures
#define ATTINY13   0x9007  // L: 0x6A, H: 0xFF             8 pin
#define ATTINY24   0x910B  // L: 0x62, H: 0xDF, E: 0xFF   14 pin
#define ATTINY25   0x9108  // L: 0x62, H: 0xDF, E: 0xFF    8 pin
#define ATTINY44   0x9207  // L: 0x62, H: 0xDF, E: 0xFF   14 pin
#define ATTINY45   0x9206  // L: 0x62, H: 0xDF, E: 0xFF    8 pin
#define ATTINY84   0x930C  // L: 0x62, H: 0xDF, E: 0xFF   14 pin
#define ATTINY85   0x930B  // L: 0x62, H: 0xDF, E: 0xFF    8 pin

byte shiftOut (byte val1, byte val2) {
  int inBits = 0;
  //Wait until SDO goes high
  while (!digitalRead(SDO)) wdt_reset();
  unsigned int dout = (unsigned int) val1 << 2;
  unsigned int iout = (unsigned int) val2 << 2;
  for (int ii = 10; ii >= 0; ii--)  {
    digitalWrite(SDI, !!(dout & (1 << ii)));
    digitalWrite(SII, !!(iout & (1 << ii)));
    inBits <<= 1; inBits |= digitalRead(SDO);
    digitalWrite(SCI, HIGH);
    digitalWrite(SCI, LOW);
  }
  return inBits >> 2;
}

void writeFuse (unsigned int fuse, byte val) {
  shiftOut(0x40, 0x4C);
  shiftOut( val, 0x2C);
  shiftOut(0x00, (byte) (fuse >> 8));
  shiftOut(0x00, (byte) fuse);
}

void readFuses () {
#if 0
  byte val;
        shiftOut(0x04, 0x4C);  // LFuse
        shiftOut(0x00, 0x68);
  val = shiftOut(0x00, 0x6C);
  Serial.print("LFuse: ");
  Serial.print(val, HEX);
        shiftOut(0x04, 0x4C);  // HFuse
        shiftOut(0x00, 0x7A);
  val = shiftOut(0x00, 0x7E);
  Serial.print(", HFuse: ");
  Serial.print(val, HEX);
        shiftOut(0x04, 0x4C);  // EFuse
        shiftOut(0x00, 0x6A);
  val = shiftOut(0x00, 0x6E);
  Serial.print(", EFuse: ");
  Serial.println(val, HEX);
#endif
}

unsigned int readSignature () {
  unsigned int sig = 0;
  byte val;
  for (int ii = 1; ii < 3; ii++) {
          shiftOut(0x08, 0x4C);
          shiftOut(  ii, 0x0C);
          shiftOut(0x00, 0x68);
    val = shiftOut(0x00, 0x6C);
    sig = (sig << 8) + val;
  }
  return sig;
}

uint8_t programmed = 0;

void setup() {
  digitalWrite(RST, HIGH);  // Level shifter is inverting, this shuts off 12V
  digitalWrite(VCC, LOW);   // start with power off
  pinMode(RST, OUTPUT);
  pinMode(VCC, OUTPUT);
  pinMode(SDI, OUTPUT);
  pinMode(SII, OUTPUT);
  pinMode(SCI, OUTPUT);
  pinMode(SDO, OUTPUT);     // Configured as input when in programming mode

  wdt_delay(1000);          // wait for battery

  pinMode(SDO, OUTPUT);     // Set SDO to output
  digitalWrite(SDI, LOW);
  digitalWrite(SII, LOW);
  digitalWrite(SDO, LOW);
  digitalWrite(RST, HIGH);  // 12v Off
  digitalWrite(VCC, HIGH);  // Vcc On
  delayMicroseconds(20);
  digitalWrite(RST, LOW);   // 12v On
  delayMicroseconds(10);
  pinMode(SDO, INPUT);      // Set SDO to input
  delayMicroseconds(300);
  unsigned int sig = readSignature();
  readFuses();
  if (sig == ATTINY13) {
    writeFuse(HFUSE, 0xFF);
    writeFuse(LFUSE, 0x3A);
    programmed = 1;
  } else if (sig == ATTINY24 || sig == ATTINY44 || sig == ATTINY84) {
    writeFuse(EFUSE, 0xFE);
    writeFuse(HFUSE, 0xD5);
    writeFuse(LFUSE, 0xE2);
    programmed = 1;
  } else if (sig == ATTINY25 || sig == ATTINY45 || sig == ATTINY85) {
    writeFuse(EFUSE, 0xFE);
    writeFuse(HFUSE, 0xD5);
    writeFuse(LFUSE, 0xE1);
    programmed = 1;
  }
  readFuses();
  digitalWrite(SCI, LOW);
  digitalWrite(VCC, LOW);    // Vcc Off
  digitalWrite(RST, HIGH);   // 12v Off

  // tristate all except VCC and RST
  pinMode(SDI, INPUT); digitalWrite(SDI, LOW);
  pinMode(SII, INPUT); digitalWrite(SII, LOW);
  pinMode(SCI, INPUT); digitalWrite(SCI, LOW);
  pinMode(SDO, INPUT); digitalWrite(SDO, LOW);
}

void loop() {
  // blink
  wdt_delay(500);
  digitalWrite(VCC, HIGH);
  if (programmed)
    wdt_delay(500);
  else
    wdt_delay(100);
  digitalWrite(VCC, LOW);
}

I believe this covers the majority of the details. The main difficulty with the t13 or t85 is that HV requires all of the pins. As a word of explanation, I use a 10 pin connector that I often have an nRF24L01+ module plugged into, but I can pull out to connect a programmer (HV or SPI).

[zw]

Maybe this is slightly off-topic for the bug, but seeing as discussion seems to have covered HV...

Personally I'm comfortable with ISP; never had to recover via HV so never built it; wouldn't shell out for a MkII JTAGICE clone, nor a Dragon. I also have things it'd be useful to debug in place but which might disapprove of the HV spike. Once debugging was finished, it'd be good to restore the ability to reset physically, and nice to restore serial auto-reset on things like Pro Minis that aren't complicated by a permanent USB<->UART loading the /RESET line. So a low-cost/low-hassle way to flip DWEN back off would be good.

So while it doesn't quite solve @plasticassius's goal of being able to consign all other programmer types to the bottom of a drawer, has anyone tried replicating "The second option"? Seems to say that once you've achieved a debugWire reset, you're left in a state where (normal-voltage) ISP programming should work again (perhaps there are conditions attached, such as not touching the /RESET line?). If it's been made to work, it might be worth making prominent in the README.

As an aside: dwire-debug's top-level README.md says:

special-pupose hardware like the AVR-ICE or AVR-Dragon (although one of these is needed initially to program the DWEN fuse which enables the DebugWIRE port)

Is that something specific to ATTiny? While I've never programmed DWEN on ATMega328, it's my understanding that avrdude is happy to do it in ISP mode, which just needs another ATMega board and the readily available ArduinoISP firmware. Wouldn't want any fellow cheapskates to be put off this project thinking that fancier programmers were required!

[zw]

I'm sure it's easy to get from the avrdude source, but it looks like my wanderings found a forum-posted version already:

As far as I can tell, the way it is done is by sending a CMND_RESET with FLAG set to 0x04 ("reset with MonCom disable" - see AVR067 - JTAGICE mkII Communication Protocol) to the ICE, which disables the debugWire interface and enables the SPI interface, and then the SPI interface can be used to reprogram the DWEN fuse. This is effective as long as the chip power is not cycled.

And here's someone using the feature.

Apologies if all this is known and obvious to you, but it wasn't to me.

[dcwbrown]

As far as I understand it, AVRdude does not talk the debugWIRE protocol directly, rather it talks the dragon or jtagice protocols, and those units translate it to debugWire - i.e. (being pedantic here) that 04H code is not a debugWire command but a jtagice command.

Nevertheless, yes, from RikusW's analysis, it's just a matter of sending a single byte (actually 06H) down the debugWIRE interface. This should reset the device and leave it with debugWire temporarily disabled and thus ISP available.

However ISP means more hardware connections. As well as the reset line, it uses MOSI, MISO and SCK. So to benefit from taking the device out of debugWIRE mode, you would need an ICE connected to your device as well as the FT232 being controlled by dwdebug.

But then if you have an ICE connected, you wouldn't need dwdebug to send the 06H, as the ice would do so. I'm pretty sure avrdude does this automatically.

Summary: it would be trivial to add a 'reset and temporarily disable debugWIRE' command to dwdebug, but I don't see a use case.

Probably I'm missing something?

BTW, thanks for your points about the readme sounding overly discouraging - I'll generalise it and mention the ArduinoISP option.

(I wasn't aware of the ArduinoISP -- nice -- it might make a great alternative to the FT232L for dwdebug. With the capability of the ArduinoISP dwdebug could control the flags and switch in and out of debugWIRE mode all by itself. I wonder how much work the AuduinoISP firmware would need to provide as USB accessed API for the debugWIRE protocol. Interesting project for another day.)

[zw]

you would need an ICE connected to your device as well as the FT232
...
I don't see a use case.

This is more a question of money/tools/access than a technical point. It sounds like you already have an ICE; I don't, and they're discouragingly expensive to many people who tinker just for fun and/or on a budget. In the Arduino world the ATMega328 is (or certainly was) by far the most popular chip, and only supports debugWire (no JTAG), so before dwdebug the only debugging choices were to buy a debugWire-capable thing (Dragon, ICE MkII, maybe some newer ones), or make do with printf-style debugging.

The programming-only (ISP) choices are much better; DIY/clone ISPs are dirt cheap and can flip fuses. So a good proportion of Arduino-ers have an ISP but not hardware ICE; they already have a bit of kit which will flip DWEN on. But if they do, without support for the alternate reset, they're trapped; they can't set fuses any more, including being unable to disable DW and regain the /RESET pin; they'd have to either buy or borrow an ICE or build an HV thing (not nearly so common, and sufficiently faffy that many sites documenting the DWEN fuse broadly compare setting it with bricking the MCU). With support for the alternate reset, they need not buy or build anything to regain fuse (and thus /RESET) control.

The Arduino world basically ruled out enthusiast-compatible debugging support and wanted to make reset convenient, so unfortunately most Arduino boards couple /RESET to DTR or RTS on a USB/UART chip via a capacitor, and thus would probably need to be physically hacked to remove that load. But that hack is documented, and the Pro Mini is free of that concern.

[zw]

I wasn't aware of the ArduinoISP -- nice -- it might make a great alternative to the FT232L for dwdebug.

The way I see it, dwdebug is ultimately destined to be an upgrade to the standard FOSS tooling:

• dwdebug should be a library
• avrdude should use it to offer direct DW-mode flashing via libftdi
• avarice should use it to offer direct DW-mode debugging via libftdi

But I'm sure there are reasons you didn't do it that way.

For those wanting a ICE-like appliance, ArduinoISP would not be enough; it implements AVR068 which was only ever for ISP, not for ICE. But with a sufficiently portable dwdebug library, firmware like debugwire-programmer or usbprog that implements AVR067 could use it; before dwdebug there'd have been little point (a MkII without DW is just an overcomplicated STK500) but now there is.

[dcwbrown]

Lots of interesting info, thanks zw. Until recently I have only looked at working directly with the attinys, and I had little knowledge of all things Arduino. Since your email I have looked further.

First with regard to ICE vs ISP and costs. Yes, It really annoyed me that there was no low cost programming and debugging platform and this stopped me going anywhere with Atmel for years. Eventually I gave in and bought a Dragon - the cheapest approach but still about £50 which, I agree, is a heck of a lot.

Then I found the Atmel tools way too clunky. Even avrdude is somewhat clunky. I suppose that's maybe forgiveable due to the wide range of devices it has to support and that it has to go through the tool interfaces, but I still really dislike it.

If I understand correctly you are pointing out that there are plenty of people out there with cheap ISP rather than ICE tools, and that if dwdebug supported debugwire disable they could be used. It would mean having both the ISP and the FT232 connected at the same time, but yes, I hadn't thought of that, and now I see how that would work.

I'll add a command for that.

---

Further I looked into using an Arduino Nano in place of an FT232.

Hardware wise I don't see why an ArduinoISP board is necessary. Nano's are easily available and can be very cheap - cheaper than FT232 boards.

I doubt there's a lot of code required to make a glorified usb to serial converter with ISP pins as well as debugWIRE, and built in debugWire baud rate detection. Even if it needs to be bit-banged to work at arbitrary baud rates and switch easily between transmit and receive on the same pin, that's not difficult.

Dwdebug would need very little change, and could take over the fuse programming automatically. Maybe something I'll get around to ...

---

Then again there are your aspirations in your second message :-).

Thanks for the info about AVR067 and 068 interfaces, I had no idea these were well documented.

Yes, I guess Implementing AVR067 could make the nano host look like an ICE and work with Atmel Studio, avrdude and avrice etc. I see that could benefit a lot of people. But I suspect the AVR067 interface would take a long time to develop and debug.

It looks like more effort than building dwdebug itself. Have you developed an AVR067 implementation?

[plasticassius]

I'm not familiar with most of the tools mentioned. I've been using the do it yourself kind like the HV programmer I mentioned before. For completeness, the other ones are Little-Wire and micronucleus. All of these can be used on a bare t85 or a Digispark which is essentially a t85 with a USB connector and has widely available clones. Also, Little-Wire is avrdude compatible via the usbtiny protocol. At this point dwdebug has allowed me to stop using micronucleus entirely since it has all of the functionality, no flash usage, and fewer wires!

I think that a t85 would lend itself well as a FT232 replacement as well as offering a number of advantages such as allowing any AVR compatible power supply voltage and being able to measure the baud rate from a single 0x55 byte. Implementing this has been in the back of my mind for a while now.

[dcwbrown]

I committed a 'qdd' command -- quit and disable debugWIRE -- yesterday. DebugWIRE remains disabled until the power is cycled.

I am now looking at using the digispark as an alternative to an FT232, and adding ISP programming support.

So far I've worked out that

• I need the v-usb implementation from micronucleus, as that
  • has been updated for Win10 support and
  • has higher bandwidth owing to fewer re-transmissions
• I'll base my v-usb client firmware around the hid code in the v-usb hid-data example app, as this works with Windows without requiring libusb-win.
• I'll build the firmware as an arduino sketch.

Hopefully these will work together.