Dragon: mega slow at dumping Flash, normal ?

[rew]

On Tue, Jun 30, 2009 at 10:10:48AM +0930, Daniel O'Connor wrote:

> On Tue, 30 Jun 2009, Vincent Trouilliez wrote:
> > On Mon, 29 Jun 2009 23:40:31 +0930
> >
> > "Daniel O'Connor" <darius@...> wrote:
> > > Terminal mode can be useful for some things but I usually only use
> > > it to change fuses or check my code has modified EEPROM as I
> > > expect.
> >
> > Same here, but I also like to have a look at the first KB's of Flash
> > as well. I found it helpful to trouble shoot string problems, or to
> > verify padding, or to check that my approximate knowledge of C's
> > syntax did put the right address in a table of function pointers, or
> > whatever... I just find it quite nice to be able to easily have a
> > quick look at the first KB's of Flash, in a formatted way, while
> > having also access to EEPROM and fuses and everyting, all from the
> > same place. IOW... I just looove this terminal feature of avrdude
> > hence my desire for it, generally, to become as good as it can get
> > ;-)
>
> I think you'll find objdump on your resulting binary much, much
> faster :)
>
> I have the following makefile rules too (BSD make though)..
>
> CPPFLAGS+=-Wa,-adhlmsn=${<:T:S/.c/.lst/}
> LDFLAGS+=-Wl,-Map=${PROG}.map,--cref
>
> .elf.dmp:
> ${OBJDUMP} -S ${.IMPSRC} > ${.PREFIX}.dmp
>
> This gives you a lot of information about how the compiler has decide to
> build your code.

But Vincent will reply...

but now you're dumping the image on the computer, not the hardware AVR
chip.

Right! However, with modern programmers, after testing things one or
two times, downloading things into the AVR chip is highly reliable. So
viewing the actual chip is no longer neccesary, as long as you don't
forget the download-to-the-chip command...

        Roger.

--
** R.E.Wolff@... ** http://www.BitWizard.nl/ ** [phone] **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Vincent Trouilliez]

On Tue, 30 Jun 2009 08:57:49 +0200
Rogier Wolff <R.E.Wolff@...> wrote:

> But Vincent will reply...

But Vincent will reply what ?!
Please see my reply to Joerg last about that... you will see that I was
quite happy with this method, and have already modified my makefile to
suit !
... but maybe you don't even read my replies properly before posting
your own...

--
Vince, GRRR !!!!


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Vincent Trouilliez]

On Mon, 29 Jun 2009 07:26:17 -0500
David Kelly <dkelly@...> wrote:

> You insist on programming in ISP mode, doesn't your AVR have JTAG  
> mode? (Generally JTAG has to be enabled from ISP.)
>
> Anyway, the device programs quickly in JTAG, thats the only mode I  
> use once the part has been initialized.

Update !
David, I have just converted one of my prototypes from ISP to JTAG this
evening, and WOW ! Terminal mode is now super fast with the Dragon,
dumping the flash is blazing fast ! :-) And maybe more
important/useful: I have done a programming test, and with JTAG the
Dragon can program the target very fast, about 6 times faster than
using ISP (regardless of programmer type and clock speed).
My 12.5KB program is now programmed in 0.98s versus 6.22 using ISP !
Reading back/verifying is also faster, 3 times faster: 1.17s vs 3.46s !

So all is well then.. I am finally happy with my Dragon. Was worth the
trouble of importing it (thanks for easing the pain, Graham ! ;-),
gives mes the sort of performance I was expecting.

Sorry for the noise and have a good week-end ! ;-)

--
Vince, les Dragons c'est bon...


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Joerg Wunsch]

Vincent Trouilliez <vincent.trouilliez@...> wrote:

> I have done a programming test, and with JTAG the
> Dragon can program the target very fast, about 6 times faster than
> using ISP (regardless of programmer type and clock speed).

This is basically known for the AVR Dragon.  If you want really fast
ISP (which only makes sense if your AVR clock speed is high), get an
AVRISPmkII: optimum (i.e., AVR clocked with 16 or even 20 MHz), it's
twice or more as fast as JTAG.

Apart from that, JTAG is pretty fast.  On the plus side, the JTAG
programming speed is completely independent of the target's clock
speed (the target is not even required to have a working clock at
all), as JTAG has its own clock.  (Only when debugging through JTAG,
the JTAG clock must (again) not exceed fCPU/4.)

Even though the ISP implementation that is embedded into the JTAG ICE
and AVR Dragon is basically the same as an AVRISPmkII, for some reason
it cannot reach the ISP speed of the AVRISPmkII.  My guess is this is
due to wrapping the AVRISPmkII protocol within the JTAG ICE mkII
protocol, causing additional overhead.

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

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


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Vincent Trouilliez]

On Sat,  4 Jul 2009 00:03:19 +0200 (MET DST)
j@... (Joerg Wunsch) wrote:

> Apart from that, JTAG is pretty fast.

I remember that you told me (a year ago maybe..) not to expect JTAG to
be very fast because its protocol included many delays which slowed
things down. Hence why I was a little surprised, but pleased, to see
that it is fast enough to my taste despite these delays.

> On the plus side, the JTAG programming speed is completely independent of the target's clock
> speed (the target is not even required to have a working clock at
> all), as JTAG has its own clock.

Yes, that's one of the reasons I fancied JTAG.. because if you get the
clock fuses wrong, it's easy to correct them via JTAG... but not so
easy/convenient with ISP.. been there done that ! ;-)
That said, ISP does have a clock signal too ! So fundamentally, I don't
understand why ISP requires the target to also have its clock working ?
Nevermind...

>  (Only when debugging through JTAG,
> the JTAG clock must (again) not exceed fCPU/4.)

Oops, didn't know that, thanks for the info...

> Even though the ISP implementation that is embedded into the JTAG ICE
> and AVR Dragon is basically the same as an AVRISPmkII, for some reason
> it cannot reach the ISP speed of the AVRISPmkII.  My guess is this is
> due to wrapping the AVRISPmkII protocol within the JTAG ICE mkII
> protocol, causing additional overhead.

Hmm, I don't think I will leave my Dragon to go back to a pure ISP
programmer. Tonight JTAG has proved to be fast enough to my taste, and
most of all it has so many advantages/features over ISP, that I would
have to be dumb to go back to ISP I think ! ;-)

I think I will rework my PCB to suit ! :-)

--
Vince, happy bunny


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Joerg Wunsch]

Vincent Trouilliez <vincent.trouilliez@...> wrote:

>> Apart from that, JTAG is pretty fast.

> I remember that you told me (a year ago maybe..) not to expect JTAG
> to be very fast because its protocol included many delays which
> slowed things down.

You're perhaps confusing that with debugWIRE.  As debugWIRE is a
one-wire protocol, it has to live with delays, caused by RC time
constants of the circuitry.

> That said, ISP does have a clock signal too ! So fundamentally, I
> don't understand why ISP requires the target to also have its clock
> working ?

ISP is basically the SPI engine of the controller, running in slave
mode.  As the entire SPI engine is a synchronous system clocked by the
IO clock of the AVR, the IO clock must be quite a bit faster than the
ISP clock (the ISP clock line itself is sampled within the SPI engine,
and ISP clock edges are detected during that sampling).

In contrast, JTAG (outside debug mode) is also a synchronous engine,
but it is completely clocked by the JTAG master.

> Hmm, I don't think I will leave my Dragon to go back to a pure ISP
> programmer.

As long as you've got JTAG-capable controllers, sure.  However, once
you're using a smaller controller that only offers ISP, you have to
use that.

Even though debugWIRE has its deficiencies (that are mostly due to its
1-wire bus technology), once you're faced with it, it's still much
better than not being able to debug at all.

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

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


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Bob Paddock]

...
> You're perhaps confusing that with debugWIRE.  As debugWIRE is a
> one-wire protocol, it has to live with delays, caused by RC time
> constants of the circuitry.
...
> ISP is basically the SPI engine of the controller, running in slave
> mode.  As the entire SPI engine is a synchronous system clocked by the
> IO clock of the AVR, the IO clock must be quite a bit faster than the
> ISP clock (the ISP clock line itself is sampled within the SPI engine,
> and ISP clock edges are detected during that sampling).

I have a question related to debugWIRE vs SPI internal to a Tiny88.
A colleague of mine, new to AVRs, tried to use debugWIRE to step
through some code that I gave him.  In my code I turned off the SPI
port through the Power Reduction Register.

Once he hit that point, the part died.  Anyway to recover them?
I did not expect to see any interaction of the SPI and debugWIRE
myself?



--
http://www.wearablesmartsensors.com/
http://www.softwaresafety.net/
http://www.designer-iii.com/
http://www.unusualresearch.com/


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Vincent Trouilliez]

On Sat,  4 Jul 2009 09:43:55 +0200 (MET DST)
j@... (Joerg Wunsch) wrote:

> You're perhaps confusing that with debugWIRE.  As debugWIRE is a
> one-wire protocol, it has to live with delays, caused by RC time
> constants of the circuitry.

Hmmm nope. We were very much discussing JTAG as this what I was
curious/interested about back then. However it was a long time ago so I
don't remember the details of the discussion... I do remember that I
was enquiring about debugging and also chaining. Maybe these use cases
do have some little delays that programming doesn't ? Anyway...

> ISP is basically the SPI engine of the controller, running in slave
> mode.

Ah ok, didn't know that.. assumed the ISP controller was something
complex enough to require a dedicated circuitry...

> As long as you've got JTAG-capable controllers, sure.  However, once
> you're using a smaller controller that only offers ISP, you have to
> use that.
>
> Even though debugWIRE has its deficiencies (that are mostly due to its
> 1-wire bus technology), once you're faced with it, it's still much
> better than not being able to debug at all.

Well sure, if the part has no JTAG, I will have to do with whatever is
available on the chip ! ;-)

--
Vince


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Vincent Trouilliez]

On Sat, 4 Jul 2009 07:37:59 -0400
Bob Paddock <bob.paddock@...> wrote:

> I have a question related to debugWIRE vs SPI internal to a Tiny88.

Bob, bad boy, don't hijack threads ! Start a new one instead, with an
appropriate subject line ;-)

--
Vince


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[hcz-2]

Bob Paddock <bob.paddock@...> writes:

> A colleague of mine, new to AVRs, tried to use debugWIRE to step
> through some code that I gave him.  In my code I turned off the SPI
> port through the Power Reduction Register.
>
> Once he hit that point, the part died.  Anyway to recover them?

You can power cycle the part if you can prevent it from reaching the PRR
write instruction.  If you can not, use any of the other ways to
reprogram the part (e.g., HVSP).

> I did not expect to see any interaction of the SPI and debugWIRE
> myself?

So did I.  That is, until I stumbled across that behaviour ... Never
founf any mention of it in the ATmega168's data sheet (that's where I
encountered it).

Heike


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Heike C. Zimmerer-6]

Bob Paddock <bob.paddock@...> writes:

> A colleague of mine, new to AVRs, tried to use debugWIRE to step
> through some code that I gave him.  In my code I turned off the SPI
> port through the Power Reduction Register.
>
> Once he hit that point, the part died.  Anyway to recover them?

You can power cycle the part if you can prevent it from reaching the PRR
write instruction again.  If you can not, use any of the other ways to
reprogram the part (e.g., HVSP).

> I did not expect to see any interaction of the SPI and debugWIRE
> myself?

So did I.  That is, until I stumbled across that behaviour ... Never
found any mention of it in the ATmega168's data sheet (that's where I
encountered it).

Heike


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Joerg Wunsch]

Bob Paddock <bob.paddock@...> wrote:

> Anyway to recover them?

High-voltage programming.

> I did not expect to see any interaction of the SPI and debugWIRE
> myself?

· Bit 2 ­ PRSPI: Power Reduction Serial Peripheral Interface

  If using debugWIRE On-chip Debug System, this bit should not be
  written to one.

OK, the "should" should probably be written as "must not".

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

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


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[David Kelly]

On Jul 4, 2009, at 8:25 AM, Heike C. Zimmerer wrote:

>> I did not expect to see any interaction of the SPI and debugWIRE
>> myself?
>
> So did I.  That is, until I stumbled across that behaviour ... Never
> found any mention of it in the ATmega168's data sheet (that's where I
> encountered it).


I too would not have suspected it as debugWIRE is performed on the  
RESET pin.

Did a project with a '168 debugged and programed via debugWIRE which  
most all tasks the AVR performed were communicating to hardware via SPI.

--
David Kelly N4HHE, dkelly@...
========================================================================
Whom computers would destroy, they must first drive mad.





_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Joerg Wunsch]

"Heike C. Zimmerer" <lists@...> wrote:

>> I did not expect to see any interaction of the SPI and debugWIRE
>> myself?

> So did I.  That is, until I stumbled across that behaviour ... Never
> found any mention of it in the ATmega168's data sheet (that's where
> I encountered it).

It's mentioned in the description of the PRSPI bit.

In theory, if you can connect debugWIRE to the target while the
power-on reset is still active, it might be possible to take over
control of the target MCU before it is able to reprogram the PRR.  In
that case, it would be possible to overwrite the respective flash page
with something else.

In practice though, I'm afraid the only way out of that situation is
high-voltage programming.

On-chip debugging and power reduction is almost always not a very
useful combination, not even with JTAG: the OCD feature causes the
main oscillator to never stop, so there's no real power-down sleep
possible.

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

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


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Heike C. Zimmerer-6]

j@... (Joerg Wunsch) writes:

> "Heike C. Zimmerer" <lists@...> wrote:
>
>>> I did not expect to see any interaction of the SPI and debugWIRE
>>> myself?
>
>> So did I.  That is, until I stumbled across that behaviour ... Never
>> found any mention of it in the ATmega168's data sheet (that's where
>> I encountered it).
>
> It's mentioned in the description of the PRSPI bit.

It is *not* mentioned in my ATmega168 documentation (PRSPI: p. 37,
Rev. 2545D-AVR-07/04).

Heike


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Joerg Wunsch]

"Heike C. Zimmerer" <lists@...> wrote:

>> It's mentioned in the description of the PRSPI bit.

> It is *not* mentioned in my ATmega168 documentation (PRSPI: p. 37,
> Rev. 2545D-AVR-07/04).

Which is arguably *way* outdated then.  The version I've been looking
at was rev G, dated 06/06, current is rev Q 04/09.

Yes, it seems revision G added this description, according to the
revision change log.

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

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


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Heike C. Zimmerer-6]

j@... (Joerg Wunsch) writes:

> "Heike C. Zimmerer" <lists@...> wrote:
>> It is *not* mentioned in my ATmega168 documentation (PRSPI: p. 37,
>> Rev. 2545D-AVR-07/04).
>
> Which is arguably *way* outdated then.  The version I've been looking
> at was rev G, dated 06/06, current is rev Q 04/09.

Yes.  Seems like the updated data sheet would have saved me some hours
and some grief (if it had been available then).

Heike


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat