Needs to be a low Cjo Schottky as a 5V USB UART with a low Vcc AVR will cause RESET(dW) -0.5V limit to be exceeded.

SB120 would be better though the best solution is to patch a low Cjo SMD Schottky.

Maybe one from the RB751 series but its forward voltage may be too large for a low Vcc AVR that's at freezing ambient.

BAT54 is better; SOD123 or SOT23 (single, not the duals), low forward voltage well below freezing, leaky, capacitance of 10pF max is too large for 5V USB UART and 2.5V AVR

BAT54 is from more than several manufacturers; can be patched (1.8mm or 3.3mm pitch) though would be easier on a snippet of protoboard (can add pins and/or sockets to create a dwire-debug adapter)

To reduce EOS with a USB UART and AVR (large) voltage mismatch, insert a 499 to 1Kohm resistor between USB UART TXD and BAT54's cathode.

This will be marginal (dW floor, overshoot) with a 2V AVR.

The excessive overshoot is corrected by decreasing TXD's transition speed via inserting a capacitor to ground between an 499 ohm resistor and the Schottky diode's cathode; 1nF for 1N5817, 47pF for BAT54.

Note:

RESET(dW) doesn't have an ESD diode to VCC so observe your ESD training.

If concerned, there are low Cjo TVS that will clamp well before RESET's 13V abs max yet not leak too much at 5V operating.

ESD damage initially manifests as leaky transistors unless the ESD/EOS/EFT/lightning has enough energy then the FET's body diode will short or the gate oxide will be punched through.

Some ESD generates enough EMP to destroy electronics across a small room due to induction (wires are an antenna)

Could try a new mega328P if you think the current one's RESET(dW) signal is flaky or the EOS may have damaged the debugWIRE machine.

I agree logic levels could be to blame, but we're that the case I would expect all operations to exhibit the same hit/miss ratio. I also agree that the added load of erase/program operations could tip the scales, but we're that the case I would expect that erase operations would fail in equal measure to write operations. They do not. I had been using an all-0xFF binary file to 'erase' the chip during testing. I don't believe I have seen that fail. Only write operations with 'non-empty' payloads seem to fail.

I have more testing to do, and I'll implement your suggestions, but it will likely not happen until at least next week, because I am here:

"Experience is what enables you to recognise a mistake the second time you make it."

The only time I wouldn't mind a faster connection is when programming a lot of flash, but it's not really been a serious issue.

dwdebug is very careful not to erase or program unnecessarily.

Single-stepping via GDB/DDD or similar, with data watch windows, can require polling large data blocks and the entire register file. Would be nice if that could be faster. I notice a real difference between running a 1 MHz target with a 7.8kbps dW speed v.s. a 16 MHz target with a 125kps dW speed.

"Experience is what enables you to recognise a mistake the second time you make it."

OK, I couldn't wait. A quick build and test with a 328P suggests the problems I had earlier with intermittent success at programming the328P have disappeared. A quick return to the old build shows those problems remain intermittent, so whatever it was appears to have been resolved with the latest repo.

r29 issue appears to have been remedied as claimed. Other testing will have to wait.

"Experience is what enables you to recognise a mistake the second time you make it."

GDB/MI is a line based machine oriented text interface to GDB. It is specifically intended to support the development of systems which use the debugger as component of a larger system. See The GDB/MI Interface in the GDB manual.

Note how the content of address 0x1e through 0x40 match that of the machine code view from ddd, confirming that it is pulling from SRAM and not flash. Except for the word at 0x001E (which is EEARH:L), and at 0x003E (which is SPH and SREG), the remaining words match, so it would seem that flash addresses are getting converted to SRAM addresses before issuing the commands to the avr-gdb backend.

In a similar vein, attempts to display data memory fail with addresses associated with SRAM i.e. offset by 0x800000.

I'm afraid I have no idea how to drive this thing, and debugging directly at the dwdebug command line seems onerous. I'll likely live without debugging for a while yet ;-)

"Experience is what enables you to recognise a mistake the second time you make it."

Thanks for the reminder! Something in the back of my memory was nagging me. Some years ago I'd fiddled with simulavr and ran into the same problem. As I recall, when I used avr-gdb (v7.8) from Atmel's toolchain, it was broken in this way. If I rolled back to my distro's v6.4, the problem went away. I think it created other problems, though. I don't remember.

When I have time, I'll try that here with dwdebug and report back.

Comment 20 Eyck Jentzsch 2017-04-04 18:47:21 UTC

Hi,
the submission of the patch to gdb-patches is more than a year old. Is there any estimate when this patch will become part of the main line?

Oy. Nearly six-year-old thread, and still not resolved :(

"Experience is what enables you to recognise a mistake the second time you make it."