Re: [avrdude-dev] AVR Dragon problem with avrdude

[Joerg Wunsch]

As Torsten Knodt wrote:

> I've tested your new AVR Dragon implementation with a Tiny
> 2313. Like already mentioned on avrfreaks, reading and writing in
> ISP mode fails (log attached) - PP mode works.

That's actually an interesting log...

All the stuff sent to the Dragon starts out to work, until the point
where the flash memory is going to be read.  As is typical for our
STK500 v2 implementation, all of the single-byte access is performed
using "SPI multi" commands, i. e. the normal ISP commands (that would
also be used with a dumb programming dongle) are just passed on to the
emulator.

When it comes to flash writing, the ATtiny2313's flash is organized in
pages, so a different routine is used.  Now, an encapsulated ISP
command CMD_LOAD_ADDRESS is sent to the dragon (with address 0),
followed by a CMD_READ_FLASH_ISP command.  This command failes (error
status 0xa0):

avrdude: jtagmkII_send(): sending 7 bytes
avrdude: Sent: . [1b] . [17] . [00] . [07] . [00] . [00] . [00] . [0e] / [2f] . 
[03] . [01] . [14] . [01] . [00]   [20] . [82] K [4b] 
avrdude: jtagmkII_recv():
avrdude: Recv: . [1b] 
avrdude: Recv: . [17] 
avrdude: Recv: . [00] 
avrdude: Recv: . [01] 
avrdude: Recv: . [00] 
avrdude: Recv: . [00] 
avrdude: Recv: . [00] 
avrdude: Recv: . [0e] 
avrdude: Recv: . [a0] 
avrdude: Recv: . [06] 
avrdude: Recv: . [e4] 
avrdude: jtagmkII_recv(): CRC OK
avrdude: jtagmkII_recv(): Got message seqno 23 (command_sequence == 23)
avrdude: stk500v2_jtagmkII_recv(): failed

Obviously, only the people at Atmel Trondheim (who wrote the firmware)
would be able to tell you *why* it failed -- there's no other
indication in the response explaining the reason.

Anyway, what caught my attention when browsing your log was:

avrdude: jtagmkII_send(): sending 5 bytes
avrdude: Sent: . [1b] . [04] . [00] . [05] . [00] . [00] . [00] . [0e] / [2f] . 
[03] . [00] . [03] . [98] = [3d] . [f4] 
avrdude: jtagmkII_recv():
avrdude: Recv: . [1b] 
avrdude: Recv: . [04] 
avrdude: Recv: . [00] 
avrdude: Recv: . [04] 
avrdude: Recv: . [00] 
avrdude: Recv: . [00] 
avrdude: Recv: . [00] 
avrdude: Recv: . [0e] 
avrdude: Recv: . [88] . [03] . [00] . [a3] 
avrdude: Recv: . [b0] 
avrdude: Recv: . [b7] 
avrdude: jtagmkII_recv(): CRC OK
avrdude: jtagmkII_recv(): Got message seqno 4 (command_sequence == 4)
         SCK period      : 19569.47 us

19.5 ms SCK period is quite slow.  In theory, it would allow handling
a target clocked from about 200 Hz CPU clock.  So I tried to reproduce
your behaviour using my Dragon -- and succeeded.  If you turn the ISP
clock sufficiently slow, reading the flash fails.  I played a bit with
the -B option, and found out that the limit is -B 487 (i. e. an SCK
period of 487 microseconds).  Anything slower than this makes reading
the flash ROM fail, at least on the ATtiny2313.  Unlike early firmware
revisions of the Dragon, the current firmware appears to remember the
last setting now in EEPROM.

Apparently, there's some kind of overflow or alike happening at that
value inside the Dragon's firmware.  As supposedly, that part of the
Dragon's firmware has been taken from the AVRISP mkII, it would be
interesting to see whether that one behaves similar.

Anyway, I'd encourage you to write a bug report to avr at atmel.com.
It's certainly reasonable to limit the ISP clock to the low end, but
that limit should be enforced by the firmware then, i. e. any slower
value should be treated as the lowest reasonable value.  (It would be
fair to also see the limits being documented, but then, there's no
documentation about the Dragon at all so far...)

Feel free to quote my analysis in your bug report.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)