dw-link and bitrot

[surge9000]

Greetings,

Having some problems with dw-link as follows. It must surely be some really stupid thing I've forgotten to do as I had this working some months ago (around April). I would like to say I haven't changed anything. Obviously I have! so I don't want o report a bug just yet. This is necessarily long I guess, so grab a coffee before you start...

The problem: avr-gdb cant seem to talk to the target properly. Output is as follows:

$ avr-gdb -b 115200 -ex "target remote /dev/ttyACM0" Fade_attiny85.ino.elf
GNU gdb (GDB) 11.2
...
Reading symbols from Fade_attiny85.ino.elf...
Remote debugging using /dev/ttyACM0
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
(gdb) mon lasterror
"monitor" command not supported by this target.
(gdb) quit
$

Retrying acts as if it worked, but doesn't:

$ avr-gdb -b 115200 -ex "target remote /dev/ttyACM0" Fade_attiny85.ino.elf
GNU gdb (GDB) 11.2
...
Reading symbols from Fade_attiny85.ino.elf...
Remote debugging using /dev/ttyACM0
0x00000000 in __vectors ()
(gdb) mon lasterror
Last fatal error: 1
(gdb) cont
Continuing.
***Fatal internal debugger error: 1

Program received signal SIGABRT, Aborted.
0x00000000 in __vectors ()
(gdb) quit
A debugging session is active.

	Inferior 1 [Remote target] will be killed.

Quit anyway? (y or n) y
Can't kill process
$

Using a HVSP programmer, Ive confirmed the DWEN fuse is set, disabled it and we go through the cycle again.

According to the manual, both errors indicate a problem with the serial port. Notice the -b option provided to avr-gdb. I haven't tried forcing stop bits etc., they should be default. Is it worth a look? To what/how should they be set?

From the LED activity, it looks a bit like the dwire sync process is getting interrupted. I have a LED connected on the target chip (MISO). I realise dw-link needs to use ICSP (and that pin) to turn on the DWEN fuse, but it shouldn't be flashing crazily? The system LED flashes pretty randomly too. I've tried removing the MISO LED in case it's load is causing problems. It still fails.

My oscilloscope isn't good enough to see the full output on the RESET line (and decode whats happening), but I can tell the signal is nice and clean.

The current setup: Linux and an Arduino Uno connected to a breadboard with the target ATtiny chip. There is a 800mA PNP transistor for supplying controllable VCC to the target. It is sourced from the 5V pin on the Uno (max. 200mA minus what the Uno uses?).

Things that may or may not be relevant:

I'm sure I had a setup with this system working at some point. It worked so reliably I even made a little module that accomodates different ATtinys.

It was a while ago, but I'm pretty sure the Uno used to connect as a proper serial device (/dev/ttyUSB0), not /dev/ttyACM0. Not sure why it changed, but from my limited knowledge, ACM/CDC devices don't really have a baud rate. Could this be the problem? I have no idea how to get ttyUSB0 back.

The Uno is a "Funduino". As far as I can tell, it's functionally identical to a "real" one. The reset link has not been severed, I use a 10µF capacitor instead.

I have modified dw-link slightly. Mostly just changing pin assignments and inversing the VSUP references for the PNP supply.

My HVSP programmer is self-designed and built. Some functions are not fully tested or dont work yet (which is why I prefer to use dw-link for programming). This is the reason I started trying to use dw-link again - I wanted to check and debug it!

I vaguely remember going through various versions of avr-gdb to find one that I liked. Is 11.2 broken somehow?

With the mass deletion of the Internet by cloudflare/google/whoever lately, this is the only place I could find related to dw-link. I hope it's still active!

Any ideas?

surge