AVR Freaks

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:

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

But it is far from my workshop ;-)

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.

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?

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

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 :(

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.