I just finished testing dwdebug with a tiny13a running off the internal ~9.6Mhz oscillator. The baud rate was ~72kbps, or a bit time of 13.9uS. Using a 1n4148 diode connected to the TTL UART Tx line, rise time was ~3uS. This is due to the weak pull-up (~45K Ohm) on the RST pin.
After doing some experimenting with resistors and diodes, I think a ~4.7K Ohm resistor between RST and Tx is the best idea.

I have been testing and I found that CH340 based adaptors appear to work as well.

Hi! I'm using ATmega48PA + FT232R + diode. dwdebug f0 founds baud, correctly read signature but stucks at WriteDebug error. After debugging I found that it stucks at DwGetRegs(first=28,count=4) that produces cmd D0 10 1C D1 10 20 66 C2 01 20.
I tried sent this cmd manualy and found that it forced my Atmega to stuck in forever loop with sending some data. I think that mcu cant reach BP 0x1020 and tries inifinitly.
0x10 is AddrFlag() result, after replacing it with 0x0 mcu replies with 4 bytes and program working.
I can't find 0x10 bias in datasheet, can somebody explain me why it used?

This is a report that I successfully run dwire-debug on cheap PL-2303HX USB-UART dongle.
Through gdbserver run by dwire-debug, I was able to attach gdb and load/execute(continue) the code on ATMEGA328P. Other dwire-debug commands I tested also worked as expected.

Wiring is exactly same as what's described - single diode bridging between RX->TX direction, with RX also connecting to MCU's nRESET (DebugWire) port. Attached is a photo

Thanks for the great work!

There is no need for DwSend(Bytes(0x66)) before calling DwSetRegs since DwSetRegs sends the appropriate setup command.

Similarly DwSend(Bytes(0x64)) on line 144 is also redundant since the following DwOut call sends this via DwInst.

I have tested, the dwdebug can not identify atmega328pb, can you make it to support this chip?
atmega328pb use debugWIRE.
Best regards.

I was testing this project with attiny13, it was strange that the reset command gave me this error:

Could not read back timings following transfer and sync command

After some debugging, I realized the fuse set of target AVR triggered this bug:
I was using "Int. RC Osc. 9.6 MHz; Start-up time: 14 CK + 64 ms", the interval between reset command (0x07) and chip's signal+0x55 response was 79ms

When using "Int. RC Osc. 9.6 MHz; Start-up time: 14 CK + 4 ms", the interval between reset command (0x07) and chip's signal+0x55 response was 4.992ms. This time it works.

I guess the tinyUSB's wait time was too short. I haven't recompile the firmware but I think this might be the issue:

Greetings,

When playing with a simple code that uses time related interrupts to blink a LED,
I have noticed that the 'td' command does not seem to work. If I leave a break point
inside the interrupt handler, it is always called when I run the code, regardless of
calling 'td' beforehand.

Cheers.

Hi,
I got my ft232 converter finally.I give it a try but unfortunately I get the following error.
I enabled the debug-wire on my device (lfuse:0xE2 hfuse:0x9F)

sudo ./dwdebug verbose,device
Trying ttyUSB0, baud rate 150000, break length 0050, skipping [00], received 00000000, scale 20%
Trying ttyUSB0, baud rate 030000, break length 0050, skipping [00], received 00000000, scale 20%
Trying ttyUSB0, baud rate 006000, break length 0050, warning, byte read after break is non-zero., skipping [], received 00011100: 8 001200000, scale 60%
Trying ttyUSB0, baud rate 003600, break length 0050, warning, byte read after break is non-zero., skipping [], received 00110010: 8 023000000, scale 85%
Trying ttyUSB0, baud rate 003060, break length 0050, warning, byte read after break is non-zero., skipping [], received 11011010: 6 041000000, scale 95%
Trying ttyUSB0, baud rate 002907, break length 0050, warning, byte read after break is non-zero., skipping [], received 01011010: 8 061000000, scale 95%
Trying ttyUSB0, baud rate 002761, break length 0050, warning, byte read after break is non-zero., skipping [], received 00001011: 8 021010000, scale 95%
Trying ttyUSB0, baud rate 002622, break length 0050, warning, byte read after break is non-zero., skipping [], received 00001001: 8 021010000, scale 95%
Trying ttyUSB0, baud rate 002490, break length 0050, warning, byte read after break is non-zero., skipping [], received 00001001: 8 021010000, scale 95%
Trying ttyUSB0, baud rate 002365, break length 0050, warning, byte read after break is non-zero., skipping [], received 10101101: 7 051000000, scale 95%
Trying ttyUSB0, baud rate 002246, break length 0050, warning, byte read after break is non-zero., skipping [], received 00010101: 8 050100000, scale 95%
Trying ttyUSB0, baud rate 002133, break length 0050, warning, byte read after break is non-zero., skipping [], received 00000101: 8 030001000, scale 95%
Trying ttyUSB0, baud rate 002026, break length 0050, warning, byte read after break is non-zero., skipping [], received 01010101: expected result.
Finding upper bound.
Trying ttyUSB0, baud rate 002066, break length 0049, warning, byte read after break is non-zero., skipping [], received 00000101: 8 030001000
Finding lower bound.
Trying ttyUSB0, baud rate 001985, break length 0049, warning, byte read after break is non-zero., skipping [], received 00000101: 8 030001000

, warning, byte read after break is non-zero.Couldn't find a DebugWIRE device.
Backtrace:
  ConnectSerialPort+0x7e
  DeviceCommand+0xca
  HandleCommand+0x99
  ParseAndHandleCommand+0x9b
  UI+0xc5

When an ft232 is found we should take some time to find the right baud rate.

It may be possible to put the ft232 into bit-bang mode, send a break, and then measure the time periods of the pulses in the 0x55 that should be returned.

Running a command line 't 5' should trace 5 instructions.

I'm a Linux/cli guy, and wanted to try out dwire-debug since the ReadMe indicates it will work with a ttl UART from the commandline. From the readme:
"There are no library or include file prerequisites."

So far I removed -lusb from the Makefile, added a USE_USB ifdef around the USB and digispark source includes, and am still working on stripping out the UI code from the build.

Using a digispark repurposed as an UsbTiny talking to an ATTiny85. Other operations work fine. Launching gdbserver causes a SegFault. Here' the relevant error and the backtrace for the failure.

Unconnected.                            > gdbserver
Connected to ATtiny85 on UsbTiny1 at 7739 baud.
Could not read back timings following transfer and sync command


[New Thread 0x2503 of process 3903]
[New Thread 0x271f of process 3903]

Thread 3 received signal SIGSEGV, Segmentation fault.
0x0000000100196670 in usb_control_msg () from /opt/local/lib/libusb-0.1.4.dylib
(gdb) bt
#0  0x0000000100196670 in usb_control_msg () from /opt/local/lib/libusb-0.1.4.dylib
#1  0x0000000100002f9c in digisparkUSBSendBytes (up=0x1002067f0, state=20 '\024',
    out=0x1000bd1b0 <DigisparkOutBufBytes> "dd", <incomplete sequence \342\043>, outlen=23) at src/dwire/DigiSpark.c:188
#2  0x000000010000309b in digisparkBufferFlush (up=0x1002067f0, state=20 '\024') at src/dwire/DigiSpark.c:211
#3  0x000000010000324a in DigisparkReceive (up=0x1002067f0, in=0x7ffeefbff0bc "\001", inlen=4) at src/dwire/DigiSpark.c:250
#4  0x000000010000491a in DwReceive (in=0x7ffeefbff0bc "\001", inlen=4) at src/dwire/DwPort.c:42
#5  0x0000000100006dc3 in DwReadFlash (addr=0, len=4, buf=0x7ffeefbff0bc "\001") at src/commands/NonVolatile.c:106
#6  0x000000010000d16c in DisassemblyPrompt () at src/ui/UserInterface.c:43
#7  0x000000010000d40e in Prompt () at src/ui/UserInterface.c:134
#8  0x000000010000d4f7 in UI () at src/ui/UserInterface.c:153
#9  0x000000010000d533 in main (argCount=1, argVector=0x7ffeefbff130) at src/dwdebug.c:18

I don't understand the USB specific code to dig deeper. Any help would be appreciated.

Currently, PC, BP and unassemble output use word addresses.

Change to byte addresses for consistency with other tools.

Hallo,
I made a setup with an FT2232, which gives 2 ttyUSB ports.
ther result of ls -U is:

jan@coconut:/dev$ ls -U|grep USB
ttyUSB1
ttyUSB0
jan@coconut:/dev$

Dwire is connected to ttyUSB0.
With the Master branch I have no problem connecting, but with the lwire branch it proves impossible since ttyUSB1 is seen first, even if I specify ttyUSB0 on the command line.

Could you please look into that, since the lwire version has some new commands I sorely miss in the master version.

Otherwise: thumbs up for your excellent idea. I did some work already with an ft232 serial port and the lwire version. it works like a dream.
The 2 port idea is so i can have a regular rs232 connection to the test cpu as well.

By the way the cpu is attiny441.

Cheers,

jan.

$ make
gcc -std=gnu99 -g -fno-pie -rdynamic -fPIC -Wall -o dwdebug src/dwdebug.c -lusb -ldl
In file included from src/system/system.c:5,
                 from src/dwdebug.c:3:
src/system/SerialPort.c: In function ‘MakeSerialPort’:
src/system/SerialPort.c:81:9: error: implicit declaration of function ‘ioctl’ [-Wimplicit-function-declaration]
   81 |     if (ioctl(*SerialPort, TCGETS2, &config)) {Close(*SerialPort); *SerialPort = 0; return;}
      |         ^~~~~
make: *** [Makefile:48: dwdebug] Error 1

Arch Linux x86_64, glibc-2.39.

In Linux, ioctl() is defined in sys/ioctl.h but in src/system/SerialPort.c it is included only if __APPLE__ is defined.
Naive attempt to include sys/ioctl.h into SerialPort.c leads to following errors:

$ make
gcc -std=gnu99 -g -fno-pie -rdynamic -fPIC -Wall -o dwdebug src/dwdebug.c -lusb -ldl
In file included from /usr/include/sys/ioctl.h:29,
                 from src/system/SerialPort.c:11,
                 from src/system/system.c:5,
                 from src/dwdebug.c:3:
/usr/include/bits/ioctl-types.h:27:8: error: redefinition of ‘struct winsize’
   27 | struct winsize
      |        ^~~~~~~
In file included from /usr/include/asm/termios.h:1,
                 from src/system/SystemServices.c:37,
                 from src/system/system.c:1:
/usr/include/asm-generic/termios.h:15:8: note: originally defined here
   15 | struct winsize {
      |        ^~~~~~~
/usr/include/bits/ioctl-types.h:36:8: error: redefinition of ‘struct termio’
   36 | struct termio
      |        ^~~~~~
/usr/include/asm-generic/termios.h:23:8: note: originally defined here
   23 | struct termio {
      |        ^~~~~~
make: *** [Makefile:48: dwdebug] Error 1

Following patch seems to fix the issue, but it's hard to create proper pull request due to mess of C sources inclusions. I can't be sure it doesn't break build in other systems.

diff --git a/src/system/SystemServices.c b/src/system/SystemServices.c
index 7d75f87..ea4a0a6 100644
--- a/src/system/SystemServices.c
+++ b/src/system/SystemServices.c
@@ -34,7 +34,8 @@
 #ifndef __linux__
   #include <stropts.h>
 #endif
-#include <asm/termios.h>
+  #include <asm/termbits.h>
+  #include <sys/ioctl.h>
 #endif
   #include <setjmp.h>

I'm testing dwire-debug with the Lazarus IDE using gdb for debugging. When hitting a breakpoint the IDE would pop up an error notification that a External: 0 was received. According to https://sourceware.org/gdb/onlinedocs/gdb/Stop-Reply-Packets.html#Stop-Reply-Packets gdb expects a SIGTRAP (= 5) response when the target reached a breakpoint.

I've modified the responses for '?', 'c', 's' commands to "S05" in handle_command (rsp.c) and the Lazarus IDE now behaves as expected during debugging. Since this is the expected response I suggest the source gets updated accordingly.

Great work by the way.

As discussed in #15 , allow dwdebug to start and stop without affecting the microcontroller program.

By having quit start execution, dwdebug can be used as an in circuit loader. This is more convenient than an ISP programmer or bootloader since it works on a single pin.

By having device connect to the microcontroller without reseting it, dwdebug can be stopped and restarted at will without changing state. It is more convenient to not have to care about what order things are stopped and started in.

@kadamski has proposed a gdb supportmode and supplied an initial pull request.

Merge this code and adapt if necessary for cross platform support.

Very nicely done :) I never got around to integrating the protocol with a debugger. It seems like your usb-serial adapter got a pullup builtin because without a 10k pullup on reset debugwire does not work. I used a npn or pnp transistor on the tx pin to convert to open collector but a low Vf diode is even simpler if one is available. (Using npn: TX - Emitter, Vcc - 10k - Base, Vcc - 10k - Collector - Output) (Using pnp: TX - 470R - Base, Collector - Ground, Vcc - 10k - Emitter - Output)

I'm working with an ft232r and an ATtiny85 fused to E:FE, H:9F, L:62 (8MHz oscillator divided by 8, debugWIRE enabled, SPI programming enable). I can't seem to get dwire-debug to do much of anything except lock up the CPU. I'm using archlinux with gcc 6.1.1 20160802.

Was this developed using an ATtiny fused for a 16MHz CPU instead of my 1MHz? Does this work only on the ATtiny45 and not ATtiny85? I don't have my own "official" debugwire programmer so my ability to debug/develop this on my own is limited.

Any advice you have would be greatly appreciated, I'd really like to get debugwire working.

(Thanks @plasticassius).

Provide a #define to disable file chooser support on linux so that dwire-debug can be built without GTK build support installed.

Many thanks @dcwbrown , it is a great work. Only one pin (the reset pin) needed for both upload and debug, very prefect.
I use ch340+1n4007 as the debugger, the target mcu is atmega328p.
When learnning how to use this great tool, I found a strange phenomenon, as the picture shows:

I don't know if other people have encountered similar problems, the method to reproduce the problem is:

After launching "qs" command → reconnect the mcu through "dwdebug device com[n]"→ launching "g" command → press return key, then non-stop output of "nnnnnnnnn" appeared.

Close the shell and re-power debugger return to normal.

When the non-stop output of "nnnnnnnnn..." appeared, I tried to ground the RST pin briefly with a line, the result is:

P.S. If I use "qr" command instead of "qs" command, everything works very well.

While this software seems to be working reliably for attiny85, I can't really get it to work with Attiny13. I did change the Baudrate to 1200000/131 (the largest value that still works) and added an entry to characteristics:
{0x9007, 64, 64, 64, 1024, 0x2E, 32, "ATtiny13"},

Simple commands work as the device is recognized but I can't load a binary. It always hangs on read while trying to execute this huge command from writing first page. It writes 439 bytes to serial, then reads 200, 200, 8 and hangs on trying to read remaining 31.

Still to add: dump commands (ram, eeprom, flash), memory edit commands, disassemble commands, binary load and program, breakpoint, command line parameters. Most of these are prototyped and just need tidying up and simplifying.

Hi, I've finally gotten around to trying out the little-wire device, which I've wanted to do for a while now. Would you check the build errors in the linux case? It doesn't seem up to date:

make -k 
gcc -std=gnu99 -g -fno-pie -rdynamic -fPIC -Wall -o dwdebug src/dwdebug.c -lusb -ldl
In file included from src/dwire/dwire.c:2:0,
                 from src/dwdebug.c:7:
src/dwire/DigiSpark.c: In function ‘WriteUPort’:
src/dwire/DigiSpark.c:47:26: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
   Ws(", device $");   Wx((int)up->device,1);
                          ^
src/dwire/DigiSpark.c:48:26: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
   Ws(", handle $");   Wx((int)up->handle,1); Wsl(".");
                          ^
In file included from src/dwire/dwire.c:3:0,
                 from src/dwdebug.c:7:
src/dwire/Serial.c: At top level:
src/dwire/Serial.c:74:5: error: expected identifier or ‘(’ before ‘while’
     while ((entry = readdir(DeviceDir)))) {
     ^
src/dwire/Serial.c:89:5: warning: data definition has no type or storage class
     closedir(DeviceDir);
     ^
src/dwire/Serial.c:89:5: warning: type defaults to ‘int’ in declaration of ‘closedir’ [-Wimplicit-int]
src/dwire/Serial.c:89:5: warning: parameter names (without types) in function declaration
src/dwire/Serial.c:90:3: error: expected identifier or ‘(’ before ‘}’ token
   }
   ^
In file included from src/dwire/dwire.c:3:0,
                 from src/dwdebug.c:7:
src/dwire/Serial.c: In function ‘SerialSync’:
src/dwire/Serial.c:404:5: warning: implicit declaration of function ‘CloseHandle’ [-Wimplicit-function-declaration]
     CloseHandle(sp->handle);
     ^
In file included from src/commands/commands.c:11:0,
                 from src/dwdebug.c:9:
src/commands/GoCommand.c: In function ‘GoWaitLoop’:
src/commands/GoCommand.c:60:11: error: ‘DigisparkPort’ undeclared (first use in this function)
       if (DigisparkPort  &&  DigisparkReachedBreakpoint()) {DeviceBreak(); break;}
           ^
src/commands/GoCommand.c:60:11: note: each undeclared identifier is reported only once for each function it appears in
src/commands/GoCommand.c:60:30: error: too few arguments to function ‘DigisparkReachedBreakpoint’
       if (DigisparkPort  &&  DigisparkReachedBreakpoint()) {DeviceBreak(); break;}
                              ^
In file included from src/dwire/dwire.c:2:0,
                 from src/dwdebug.c:7:
src/dwire/DigiSpark.c:170:5: note: declared here
 int DigisparkReachedBreakpoint(struct UPort *up) {
     ^
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:219:0,
                 from src/system/SystemServices.c:18,
                 from src/system/system.c:1,
                 from src/dwdebug.c:3:
src/commands/GoCommand.c:64:14: error: ‘SerialPort’ undeclared (first use in this function)
       FD_SET(SerialPort, &readfds);
              ^
In file included from src/commands/commands.c:11:0,
                 from src/dwdebug.c:9:
src/commands/GoCommand.c:72:18: warning: implicit declaration of function ‘Flush’ [-Wimplicit-function-declaration]
         Ws("."); Flush();
                  ^
Makefile:44: recipe for target 'dwdebug' failed
make: *** [dwdebug] Error 1
make: Target 'all' not remade because of errors.

I made up a cable to use avrdude or dwire-debug as required.
here is the proof:

quitting dwire-debug:

0000: c01d rjmp 003c (+30) > qi

starting avrdude (the device must stay powered up):

$ ./avrdude -C ./avrdude.conf -pt441 -P/dev/ttyUSB0 -cjanser -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.67s

avrdude: Device signature = 0x1e9215
avrdude>

Here are the avrdude details for the programmer:

programmer
id = "janser";
desc = "jan's ftdi serial bitbanger, reset=!txd sck=!rts mosi=!dtr miso=!cts";
type = "serbb";
connection_type = serial;
reset = ~ 3;
sck = ~ 7;
mosi = ~ 4;
miso = ~ 8;
;

NOTE: I run this straight out of an fd2232 chip without any rs232 buffers. if you use inverting buffers in the signal path you will have to change the polarity of the signals above also.

There is no great secret about the pdf I enclose. And the circuit might not even be 100% perfect yet. It is merely to show the programming header connections.
The program header is standard ATMEL with the added pin 7 and the diode to the reset of the chip.
So the TxD wire on pin 7 works as the reset in avrdude mode and as the command data wire in dwire-debug mode. Pin 5 (Reset) is effectively not used in avrdude mode, but has the RxD connected to it for dwire-debug mode.

PC - DB9 - Pins for RS232: programming header

pin2 of the header has 3v3 (not always used)

fuzz-thermostat.pdf

Enjoy,
j.

I have a ATtiny84a. Everything worked until I tried to upload new code via debugwire:

Unconnected.                            > device tty.usbserial-AH06TDUZ
Connected to ATtiny84 on /dev/tty.usbserial10 at 30949 baud.
fffffffe: ffff                          > l src/main.elf
Loading 308 flash bytes from ELF text segment 0 to addresses $0 through $133.
SerialRead expected 256 bytes, received 112 bytes
64  64  d2  b5  d7  23  01  64  d2  b5  e7  23  00  64  d2  b5  f7  23  00  64  64  64  d2  b4  07  23  10  64  d2  b4  17  23  e0  d0  00  00  64  d2  bf  d7  23  64  d2  95  e8  23  64  d2  96  32  23  64  64  d2  b4  07  23  a0  64  d2  b4  17  23  e6  d0  00  00  64  d2  bf  d7  23  64  d2  95  e8  23  64  d2  96  32  23  64  64  d2  b4  07  23  b0  64  d2  b4  17  23  e0  d0  00  00  64  d2  bf  d7  23  64  d2  95  e8  23  64  d2  96  32
SerialRead expected 256 bytes, received 198 bytes
23  64  64  d2  b4  07  23  e4  64  d2  b4  17  23  e3  d0  00  00  64  d2  bf  d7  23  64  d2  95  e8  23  64  d2  96  32  23  64  64  d2  b4  07  23  f1  64  d2  b4  17  23  e0  d0  00  00  64  d2  bf  d7  23  64  d2  95  e8  23  64  d2  96  32  23  64  64  d2  b4  07  23  03  64  d2  b4  17  23  c0  d0  00  00  64  d2  bf  d7  23  64  d2  95  e8  23  64  d2  96  32  23  64  64  d2  b4  07  23  c8  64  d2  b4  17  23  95  d0  00  00  64  d2  bf  d7  23  64  d2  95  e8  23  64  d2  96  32  23  64  64  d2  b4  07  23  31  64  d2  b4  17  23  96  d0  00  00  64  d2  bf  64  64  d2  b5  d7  23  01  64  d2  b5  e7  23  00  64  d2  b5  f7  23  00  64  64  64  d2  b4  07  23  10  64  d2  b4  17  23  e0  d0  00  00  64  d2  bf  d7  23  64  d2  95  e8  23  64  d2  96  32  23  64  64  d2

Questions:

• What should I do next? quit and restart doesn't seem to work. The program is not running (or sth is running but not what should)
• Why is the application telling it's device dev/tty.usbserial10? There's no such device, only tty.usbserial-AH06TDUZ
• If I add baudrate, eg 9600 or any other value not around 30949 baud the device is not found at all, how come?
• I also tried with a CH340, but no device is found even /dev/tty.wchusbserial1420 is there :-(

Maybe someone can help me getting things going on?

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).

Works fine with ATTiny13A and CP210x. But doesn't work with ATTiny44A, because when tried to connect I got this message:

Unconnected.                            > device com5
WriteDebug, byte 1 of 1: Read 92 expected f3

SerialRead expected 24 bytes, received 18 bytes
07  92  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  55

So we see that device responds with its signature 9207 but there is no sended 0xF3 byte in receiving buffer wich dwdebug tryes to read. I tried to disable reading sended bytes in function SerialSendBytes() in Serial.c and modified it to:

void SerialSendBytes(struct SPort *port, const u8 *out, int outlen) {
  Write(port->handle, out, outlen);
  return;
}

And now dwdebug see the avr:

Unconnected.                            > verbose
Unconnected.                            > device com4
Debug: devicename 'com', n 4.
Debug. DwFindPort(s, 4, 0)
 -- ConnectSerialPort entry. SPort: kind s, index 4, character -1, baud 0, handle $0, portname COM4.
COM4 Trying COM4, baud rate 150000, break length 0050, skipping [00], received 00000000, scale 20%
Trying COM4, baud rate 030000, break length 0050, skipping [0], received 01111000: 8 010110000, scale 40%
Trying COM4, baud rate 012000, break length 0050, skipping [0], received 10010011: 7 013000000, scale 85%
Trying COM4, baud rate 010200, break length 0050, skipping [0], received 01101001: 8 042000000, scale 85%
Trying COM4, baud rate 008670, break length 0050, skipping [0], received 10101101: 7 051000000, scale 95%
Trying COM4, baud rate 008236, break length 0050, skipping [0], received 01010101: expected result.
Finding upper bound.
Trying COM4, baud rate 008400, break length 0012, skipping [0], received 10110101: 7 051000000
Finding lower bound.
Trying COM4, baud rate 008071, break length 0012, skipping [0], received 01010101: expected result.
Trying COM4, baud rate 007909, break length 0012, skipping [0], received 01010101: expected result.
Trying COM4, baud rate 007750, break length 0012, skipping [0], received 01010101: expected result.
Trying COM4, baud rate 007595, break length 0012, skipping [0], received 01010101: expected result.
Trying COM4, baud rate 007443, break length 0012, skipping [0], received 01010101: expected result.
Trying COM4, baud rate 007294, break length 0012, skipping [0], received 10110101: 7 051000000
 -- TryConnectSerialPort complete. SPort: kind s, index 4, character -1, baud 7839, handle $218, portname COM4.
 -- ConnectSerialPort complete. SPort: kind s, index 4, character -1, baud 7839, handle $218, portname COM4.
Connected to ATtiny44 on COM4 at 7839 baud.
0040: bb8a  out   $1a, r24              > r
r0 c1   r4 cf    r8 14   r12 13   r16 4f   r20 b8   r24 00   r28 5f
r1 00   r5 c8    r9 22   r13 5b   r17 9c   r21 32   r25 00   r29 e1
r2 dd   r6 71   r10 bb   r14 9c   r18 00   r22 47   r26 61   r30 3a
r3 af   r7 12   r11 9e   r15 8e   r19 00   r23 9e   r27 00   r31 00
SREG i t h s v n Z c    PC 0040  SP 015f   X 0061   Y e15f   Z 003a
0040: bb8a  out   $1a, r24              >

Hallo,
can I zero a block of RAM with the 'wd' command?
I am short of memory so I would dearly like to see if I overwrite my tail with the stack.

Cheers
j.

I am using a HL-340 USB-TTL adaptor.
I can connect to a ATMEGA328P through dwdebug and debug it. However, writing to flash appears to fail. I have tried both through gdb (using eclipse) and directly using the l command in dwdebug.It looks like it's running the old program code. When I quit debugwire and write the program to flash using avrdude, the new code can be debugged.

Hi,
I have a problem with the usbtiny used as a debugging hardware. My ftf232 usb serial working fine as debug hardware, but I can not debug the same Arduino uno with the usbtiny.
The usbtiny can program the target with the load command, can display registers and almost everything working fine except reset and gdbserver commands.
I tried to solve the problem, by using a logic analyser to see what is going on the reset line. As I saw, when the gdbserver command started, the following bytes were transferred: 0x07 0x00 (80uS) 0x55 and nothing else.
I checked the transmission with the ft232 debugger too, and right after the gdbserver command fired, I saw much more traffic then that, like 0x07 0x00 0x55 and after 16.5ms 0xF0 0x3F 0x01 and more...
So the problem is seems like the usbtiny close the communication, maybe it does not waiting enough time.

Show status of breakpoint setting in the UI somehow.

Provide option to disable or enable timers during execution and show that in the UI too.

An operator noticed that a mega328P flash write appears to successfully complete yet the flash is not written.
The hypothesis is a flash write to an AVR with BLS and greater than 8KB of flash will not occur.
Details at http://www.avrfreaks.net/forum/debugwire-usb-uart#comment-2286266

The operator created a successful patch at
http://www.avrfreaks.net/forum/debugwire-usb-uart#comment-2287136
that's copied here
patch.txt

Thank you for your creation and for consideration or effort for this issue.

This tool looks exactly like what I was looking for. Thanks! Just tried it and i had some trouble with building today's master version (on Windows 10). I downloaded Cygwin, installed the mingw64-i686-binutils and mingw64-i686-gcc-core libraries, and run make. But the code has some easily-solved issues that the compiler and linker didn't like, so i thought i'd share my changes.
In Makefile, change line:
i686-w64-mingw32-gcc -std=gnu99 -Wall -o $(BINARY) -Dwindows src/$(TARGET).c -lKernel32 -lowing -lComdlg32 -lWs2_32
to:
i686-w64-mingw32-gcc -std=gnu99 -Wall -o $(BINARY) -Dwindows src/$(TARGET).c -lKernel32 -lwinmm -lComdlg32 -lWs2_32
And in src/dwire/digispark.c, replace all 'bool' with 'int', all 'true' with '1', and all 'false' with '0'.
Cheers!