Studio 6 code download slow, normal?

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I didn't take any timings on Studio 4, but my impression is that Studio 6 is much slower in downloading code than AVR32 Studio 4 was. (Or maybe it is because the progress bar does not updating...) My application size is 114310 bytes, AT32UC3B0256 part. When I click the start debugging button, the time from the click to the application start is using JTAGICE mkII 1 min 25 sec, and I need to click a timeout window once. using a Dragon, the time is slower as expected, but not as much as expected, 1 min 45 sec.

Maybe my system has a problem? Atmel says that JTAGICE mkII "Uploads 256Kb code in ~30 seconds", while on Dragon it should take twice as long. I certainly don't get anywhere close to these. Do you see similar timings? Is there a setting somewhere I could try? The "Atmel Communication Timeout" setting does not seem to affect anything.

The firmware image on my JTAGICE is 7.19, which the Studio says is up to date.

But I'm still not going back to Studio4, the 6 is finally almost where it should be (and the interrupts can be skipped in debugging, thank you very much for this!).

Cheers,

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

There's a whoopsy in the AS6 release that will cause a lengthy firmware check on each tool on the first use of the tool in a Studio session, but after that the download time is supposed to be pretty similar to 5.1.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

It takes the same time each time. How long it is supposed to take to download 128k of code to an AVR32? Would it be any closer to the advertised time if I buy a JTAGICE3?

This is on Win XP, Sp3, btw.

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

Just tested this - with a JTAG-ICE MKII, I was able to program a UC3B with 35KB of data in 40 seconds. Trying with a JTAG-ICE3 at its maximum 7.5MHz JTAG clock it tool around 6 seconds.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

You get similar speed than I do; about third of the time, but about third of the data, too. So, the speeds are, roughly:

JTAGICE mkII: measured 1kB/s (advertised 8.5 kB/s)
JTAG-ICE3: measured 6kB/s (advertised 17kB/s)

Conclusions:
-Studio 6 is very slow (compared to whatever software was used to get the numbers at Atmel web site).
-With Studio 6, JTAG-ICE3 is 6x the speed of JTAGICE mk2 (but still slower than advertised).

Hopefully, the bottleneck will be cleared in 6.1. In the meanwhile, I'll buy an JTAG-ICE3; thank you for testing it for me!

Cheers,

Juha

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

I can confirm that there is indeed a bottleneck when programming UC3 devices.

To speed things up for debugging, we (usually) have some specific ways of accessing flash memory for debugging and some other ways for programming.

Unfortunately, in the Atmel Studio 6.0 release, we use the debug access method for programming. In AVR studio 5.1 we did not.

Some measurements done today, comparing a fixed version with the 6.0 release show that this slowed programming down by a factor of about 3.

I am very sorry that this crept into the release.

Torleif

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

torleifs wrote:
I can confirm that there is indeed a bottleneck when programming UC3 devices.

To speed things up for debugging, we (usually) have some specific ways of accessing flash memory for debugging and some other ways for programming.

Unfortunately, in the Atmel Studio 6.0 release, we use the debug access method for programming. In AVR studio 5.1 we did not.

Some measurements done today, comparing a fixed version with the 6.0 release show that this slowed programming down by a factor of about 3.

I am very sorry that this crept into the release.

Torleif

Do you mean that even for debugging it should program the chip first and then change to jtag debug mode to reduce the start-up time but because of the bug is not happening?

Why not implement a smart update on AS6 so it could check for updates every once in a while and inform the user for bugfixes and have the ability to download and update them immediately - as i see that AS6 has many dlls - rather than to wait long time for the next release of Atmel Studio?

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

DieCore wrote:

Do you mean that even for debugging it should program the chip first and then change to jtag debug mode to reduce the start-up time but because of the bug is not happening?

When starting a debugging session the chip should first be programmed using memory accessors set up for programming mode.

After programming, new memory accessors are set up for debug mode.

The bug is that we use the debug mode accessors for programming.

DieCore wrote:

Why not implement a smart update on AS6 so it could check for updates every once in a while and inform the user for bugfixes and have the ability to download and update them immediately - as i see that AS6 has many dlls - rather than to wait long time for the next release of Atmel Studio?

We are considering various alternatives for this use case.

Torleif

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

torleifs wrote:
I can confirm that there is indeed a bottleneck when programming UC3 devices.
...
I am very sorry that this crept into the release.

Torleif


Apology accepted. :) No worries, my company can afford the JTAGICE3 (which should be here tomorrow). So, can I ask you to put that in the Bugzilla (as you know the details) and, if possible, release 6.01 as soon as possible?

Cheers,

Juha

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

The issue exists in our (internal) bugtracking system as
avrsv-3545

Torleif

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

Yes, I use avrdragon for my project (Because of its price). Is is rather slower than AVR32 Studio. And I meet an error "Debugger Times Out" when I use JPEG DECODER application. I wanted to interface an external sram to EVK1100. Unfortunately it failed when I want to move the heap space to External SRAM space.

I use Windows 7 x64 TR and Atmel Studio Production Release. I am working with AT32UC3A0512.

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

The problem has now been fixed and will be distributed in a patch in the near future.

Torleif

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

torleifs wrote:
The problem has now been fixed and will be distributed in a patch in the near future.

Torleif


Good to hear there is a fix. Any news as to when it will be available?

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

Well a patch was released about a week ago(*) so there's a pretty fair bet that something dating back to June is in it.

(*) https://www.avrfreaks.net/index.p...

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

clawson wrote:
Well a patch was released about a week ago(*) so there's a pretty fair bet that something dating back to June is in it.

(*) https://www.avrfreaks.net/index.p...


Thanks.

I'm now getting 3.6k per second

Still feels slow when downloading 136k in to a uc3 (38 seconds), but it implies a factor of three improvement (compared to the benchmarking earlier in the thread) which is what was suggested.