debugWIRE via USB UART

Go To Last Post
75 posts / 0 new

Pages

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

joeymorin wrote:
That would manifest the same as too high a baud rate.

...

Frustrating that I cannot correlate it with... anything.

ambient temperature

Hypothesis:

Switching diode's forward voltage is close to RESET's limit of 0.1 * Vcc (500mV for 5V)

 

Tool:

Heatgun

 

Test:

Heat the diode halfway to boiling.

Is dwire-debug functional?

 

Proposed Solution:

Schottky diode

One of many is BAS70 from http://www.avrfreaks.net/forum/debugwire-usb-uart#comment-2287616 at Cjo of 3pF (or near equivalent)

1N5817 is leaky with a Cjo of 200pF but it'll still work.

SB120 leaks less with a bit less Cjo.

 

Correction:

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.

 


http://www.onsemi.com/PowerSolutions/product.do?id=BAS70SL (SMD)

http://www.onsemi.com/PowerSolutions/product.do?id=1N5817 (thru-hole)

http://www.onsemi.com/PowerSolutions/product.do?id=SB120 (thru-hole)

http://www.onsemi.com/PowerSolutions/product.do?id=RB751S40 (SMD)

http://www.onsemi.com/PowerSolutions/product.do?id=BAT54 (SMD)

 

Edits : correction, RB751, BAT54, resistor, capacitor

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Oct 11, 2017 - 04:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
Is dW electrically very different to uPDI?
Yes

Like PDI, UPDI is symmetric impedance with tri-state whereas dW is open drain with active and hold pull-ups.

 

Edit : pull-ups

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Oct 10, 2017 - 06:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The debugWIRE hardware implementation fixes the baud rate at target clock speed/128.

 

So an estimated max speed of 200Kbps would theoretically support targets of up to 128 x 200KHz = 25.6MHz, a little more than the official 20MHz max speed of these AVR devices.

 

It works for me with short separated wires. I would avoid long wires, especially in close proximity as in a multiway flat cable.

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

The work by RikusW suggests baud rates as high as /8 are available, with /128 the default. Have you determined this to be untrue?

I realise that bus characteristics will dictate the maximum attainable speed, but smaller prescalers would permit faster dW comms with lower system clock speeds.

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

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Incorrect logic levels

tiny85

Input Low-voltage, RESET pin

VIL2 < 0.2 * VCC

 

mega328P

VIL2 < 0.1 * VCC

 

Though not as ubiquitous as a Schottky diode, a level converter would be functional for all dW AVR at all Vcc for the full temperature range for any voltage USB UART.

Some of the packages for such are SOIC and SOT23 so would be easy to protoboard.

 

"Dare to be naïve." - Buckminster Fuller

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

Oh yes! I just looked at RikusW's notes again. I'd forgotten all about that so I never got around to trying it.

Mostly the clock/128 speed is fine.

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.

 

 

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

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

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Filling the barn with hay and/or chopping fire wood I would guess before winter.

Or painting the barn red???

 

Jim

 

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

Actually, just visiting.  Not a working farm any more.

 

But it is far from my workshop ;-)

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

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

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

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Builds firmware and working DigiSpark-only dwdebug for Windows only.

Further work now moving to github.com/dcwbrown/dwire-debug branch 'lwire'.

joeymorin wrote:
So, I can't help you (and you can't help me!) if that is the case.

 

Suggestions?

fyi, the following issue closed today.

GitHub

/dwire-debug

build errors in linux version #23

https://github.com/dcwbrown/dwire-debug/issues/23

 

"Dare to be naïve." - Buckminster Fuller

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

Sweet!  Don't know when I'll have time to give this attention, but it is high on my list.  Thanks for the update!

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

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

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

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Just to be clear, I built from the lwire repo as suggested by the author in #49:

Oops, I was obtuse when I waffled 'the littlewire branch' wasn't I?

 

Yep you've been trying to build an obsolete repository. Sorry about that.

 

What I should have said was, 

  .  stay in the dwire-debug repository

  .  type git checkout lwire to switch to the littlewire branch

  .  run make from the root of the repository

 

Hopefully this will help ...

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

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

joeymorin wrote:
Flash is not written under an ATmega328P.  The load operation proceeds without errors, but flash is not modified.
Fixed by merging the Little Wire branch into the master branch via an issue that was closed today.

Programming does not work #29

https://github.com/dcwbrown/dwire-debug/issues/29

...

a-v-s commented a day ago

I am using a HL-340 USB-TTL adaptor.
I can connect to a ATMEGA328P through dwdebug and debug it. However, ...

...

 

"Dare to be naïve." - Buckminster Fuller

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

Well, that was short-lived.

 

The latest version barfs with this shortly after ddd connects (via avr-gdb) with 'target remote':

Attempt to read beyond end of flash.

... while ddd reports:

Remote connection closed

 

Seems ddd tries to fetch machine code past the end of flash, and dwdebug terminates.  While ddd probably shouldn't do that, I didn't have that problem with the older version of dwdebug.

 

One step forward, two steps back :(

 

Anyone know how to tell ddd how big flash is, and/or how not to read past the end?

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

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Scratch that.  The other version did that as well.  I'll have to do more testing to figure out what's stopping me from making headway with the new version.

 

Still interested in getting ddd to play nice with dwdebug.

 

Any other gdb front ends apart from ddd which someone can recommend?

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

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Oct 21, 2017 - 06:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gdbgui?

(haven't tried it)

 

GDB Wiki

GDB Front Ends

https://sourceware.org/gdb/wiki/GDB%20Front%20Ends

...

1.1. Using modern GDB/MI

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.

gdbgui - Feature rich browser-based frontend with data structure visualizations (like DDD), and gdb terminal access. Compatible with C, C++, golang, Rust, fortran. Written in Python and JavaScript. pip install gdbgui.

...

"Dare to be naïve." - Buckminster Fuller

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

I figured out what I was doing wrong with ddd and reading beyond the end of flash.  It had to do with the order in which I issued commands to ddd.

 

Now, of course, there are other issues.

 

The machine code doesn't show flash contents, but SRAM:

Dump of assembler code from 0x80001e to 0x80011e:
   0x0080001e:  std     Y+50, r10       ; 0x32
   0x00800020:  nop
   0x00800022:  nop
   0x00800024:  nop
   0x00800026:  nop
   0x00800028:  nop
   0x0080002a:  nop
   0x0080002c:  nop
   0x0080002e:  nop
   0x00800030:  nop
   0x00800032:  nop
   0x00800034:  nop
   0x00800036:  .word   0x0004  ; ????
   0x00800038:  nop
   0x0080003a:  nop
   0x0080003c:  nop
   0x0080003e:  movw    r30, r8
   0x00800040:  nop

Note the addresses which start at 0x800000.

 

Compare that to a data dump from the dwdebug command line:

> d0 50
0000:   ff 00 ff 60  04 01 10 80   12 19 0a 11  00 21 25 06   ...`.........!%.
0010:   81 01 00 00  20 f2 06 6c   3f 00 06 b0  5f 00 2f 00   .... ..l?..._./.
0020:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0030:   00 00 00 00  00 00 04 00   00 00 00 00  00 00 54 01   ..............T.
0040:   00 00 00 00  00 00 00 03   00 00 00 00  00 ff 00 00   ................

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

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

joeymorin wrote:

The machine code doesn't show flash contents, but SRAM:

Dump of assembler code from 0x80001e to 0x80011e:
   0x0080001e:  std     Y+50, r10       ; 0x32
   0x00800020:  nop
   0x00800022:  nop

Note the addresses which start at 0x800000.

Perhaps related to this gdb issue: https://sourceware.org/bugzilla/show_bug.cgi?id=13519 ?

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

Perhaps related to this gdb issue: https://sourceware.org/bugzilla/show_bug.cgi?id=13519 ?

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

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

joeymorin wrote:

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

You are welcome to try an already patched gdb 8.0 for linux x64 (if you are willing to trust a binary file downloaded from an unverified source): https://github.com/ccrause/fpc-a...

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

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

Confirm that 6.4 works (although as I said, there are other problems... mostly likely due to the fact that I don't know how to drive this thing ;-)

 

You are welcome to try an already patched gdb 8.0 for linux x64 (if you are willing to trust a binary file downloaded from an unverified source): https://github.com/ccrause/fpc-a...

I generally don't, but thanks, I may give it a try.

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

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

"Dare to be naïve." - Buckminster Fuller

Pages