AVR Studio v4.12.461 SP1 released (revision update)

Go To Last Post
86 posts / 0 new

Pages

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

hello johan,
i can confirm your observation. LED on NIC is blinking like hell as soon as i open a project.

@roland:
any idea when this problem will be solved?

regards
gerhard

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

gerhardf wrote:
hello johan,
i can confirm your observation. LED on NIC is blinking like hell as soon as i open a project.

@roland:
any idea when this problem will be solved?

We are working on it. We believe the performance problem and the network activity you see are related., but we are not yet entirely sure what operations cause this activity.

We hope to have a solution before the week-end, but I cannot guarantee that. I expect we will put out a new RC as soon as we have a solution that seems satisfactory. The only thing I am absolutely certain of is that we will not release the final version of 4.12 before this is fixed.

Update: We have solved the network activity issue, but still working at the performance issue. It turned out they are completely unrelated.

--
roland

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

Hi dear co-freaks.

Another Release Candidate, the v4.12.454 RC3, here: http://www.atmel.no/beta_ware/
Let's give it a try!

Fixes in build 454:
* Fixed performance and network problems. Projects with many files could experience major performance problems.
* ICE50 trace fix. Bug in mapping between trace data and source.
* COFF parser fix. Bug in source file mapping for functions returning pointers.
* Simulator fix. bug when using 2 AVR Studio simulator sessions at the same time.
* Fixed bug with auto open feature.
* Fixed problem that could cause network traffic on idle.
* Fixed bug in "old" plugin-in's. Bug could cause hang when using context menus.
* Various fixes in AVR-GCC project
- Bug fixed: Error messages referring to line:column not recognized.
- Enhancements: Added 'edit' button for editing options. resized optionslistbox to make room for longer options.
Double-click event on optionslistbox edits item.
- Bug fixed: renaming configuration could cause make problems.
- Bug fixed: problem with superfluous spaces.
- Order of include directories is now reflected in the build.
- Bug fixed: Add multiple libraries did not work.
- Bug fixed: Crash when changing stack settings.
- Bug fixed: removed -o option for build steps.
- Bug fixed: Better error handling for invalid configuration names.

Giorgos.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

On updating to 4.12 I see that the change to smart docking comes with a sting in the tail.

The Output and Workspace views are now composed of a number of independantly managed windows. As a result trying to change the views can be troublesome.

If for example I wish to hide and later unhide the Workspace view, previously done by toggling a tool bar icon, I need to hide each individual tab window and then use the View menu three times to recover them. Very cumbersome.

Toggling these views on/off is something I do quite regularily. Either to free up screenspace or when opening a new file the scroll bar always hides under the Workspace view ( for some reason the new file always opens twice the width it should be).

It would be good to get toolbar control of these views back.

I also see that it is no longer possible to open more than one version of a file. This is of course much safer. It would however help if when the file view was split horizontally there were scroll bars for each part of the split.

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

Have a serious performance problem with RC3 (also had this on RC1). 8 c-source files, 7 header files and about 20 External dependencies.
All worked fine until a certain point where compilation/linking suddenly started taking 15-20 seconds instead of 1-2 seconds. The GUI will freeze up during this and also the output in the build window is erratic.
First time this happened, it was after I had added some calls from the main code to functions in one of the other c-files. I tried commenting them but it was the same. I restarted the GUI and removed the comments, and everything was ok again. Have tried all variants now, but no matter what I try, it's still the same problem.
It seems like some kind of resource problem. Not on my PC though, it worked perfectly yesterday with about 17 other open programs some of which was very CPU and resource intensive. Now after the code has grown, it won't even run properly alone.
This project will otherwise compile all files in < 1 second from the command line with a regular makefile.

Also, when this happens, I cannot enter (JTAG) debug mode at all, the program will just hang. Once it actually started debug, but that was after several minutes.

Others with the same behaviour ?

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

I donwloaded multiple times on friday night, but I wasn't able to install it, the Installer said that some files are corrupted. I will try today to see if the installation process goes peaceful.

---
ARod

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

Thanks for the notification. I'll update the thread's title.

I am downloading it now.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Done!
RC4 downloaded and installed.

I do not know why, but the installer needed to restart the machine (WinXP SP2 on a Prescott), afterwards.
It seems to be all right, and I think that the simulator runs a little faster.
An older silly bug though, still exists: Studio still does insert randomly placed bookmarks.

Further testing in progress...

Giorgos.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Jesper,

The avr-gcc plug-in does some parsing of dependencies when building a project.
There is probably an error somewhere in this parsing routine.
Would you consider sending your project to avr-beta@atmel.com so I could have look at it?

Torleif

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

Torleif,
I have found out why the compile process was slow. It was due to a USB card reader being connected (and accessed).
When I disconnected it (it's mapped as drive M, standard windows mass storage drivers), all worked fine again.
If I connect it, there's no problem until I've had a card in the reader and accessed it, but then compilation again is extreeemely slow.
Note that this card, the path and the files are completely unrelated to the actual project in AVR-studio.

There's still something rotten about the debug. After I found out about the USB drive thing, it's better, but it still locks up, or is very slow to start sometimes. As soon as it starts loading code to the CPU, it's okay though.

I'll test some more and post the results here.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

Jesper,
Thanks for the clarification!

Does the USB card reader use much CPU when accessing cards?
This could (of course) slow the build process.

When do you still experience lock-ups? Is it when you are loading an avr-gcc project, or building a project? Is AVR Studio using much CPU when this happens?

Torleif

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

Jesper / Torleifs,

The M: thing is a well known problem ni avr-gcc - no doubt EW will be a long in a minute to explain it in full detail but the avr-gcc.exe has an M: path "burnt in" as a place to look for files. As long as you don't have an M: on your machine it just ignores this and steps on to look in other places but if there is either a network M: or an inserted memory card appearing as M: or something then you hit this problem. It is not a problem in Studio as such.

If you load avr-gcc.exe into a program that can pull out the ASCII strings you will find, embedded in it:

m:/WinAVR
m:/WinAVR/bin/
m:/WinAVR/lib/gcc/
m:/WinAVR/libexec/gcc/
m:/WinAVR/share/locale
m:/WinAVR/share/locale
m:/WinAVR/share/locale

which I think was the directory structure on the machine where avr-gcc.exe was built in the first place.

Cliff

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

The operation of my JTAG ICE2 programmer has changed since updating from 4.11 to 4.12 RC3. Before I could leave the programming dialog open, program a device, power off, connect another AVR, power up and program etc. Now I get a "JTAG Mode Error" when I try to program the next device, and the only way to resolve this is to close and then re-open the programmer dialog every time the target power is cycled.

A second issue is that the JTAG ICE holds the target in reset after programming until I either cycle the target power or disconnect and reconnect the JTAG ICE from the target. Very annoying when you are frequently re-programming during heavy debug sessions. This never happened with the old serial JTAG ICE under 4.11 (can't remember if this was the case with the mk2 under Studio 4.11).

I have just updated to RC4 and updated the JTAG ICE firmware, but the behaviour is still the same. Has this been changed deliberately or is it a bug?

The target in all cases is the Mega128 running at 3.3volts.

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

Currently using RC3:

Found that when I highlight a variable and I start draging with the intent of dropping into the watch window, the source code file tabs jump when my mouse curser moves over them.

Any chance this can be fixed? It's really annoying to be forced to highlight then right click to select Watch:Variable.... It is so much faster to drag/drop the variables into the watch window.

Oh and I second MikeRJ's request above regarding programming with the JTAG mkII. I believe the problems all started with V4.12 (all RC's). Very annoying to be forced to remove the JTAG to free up the reset line....

Thanks!

Monsoon

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

clawson wrote:
Jesper / Torleifs,

The M: thing is a well known problem ni avr-gcc - no doubt EW will be a long in a minute to explain it in full detail but the avr-gcc.exe has an M: path "burnt in" as a place to look for files. As long as you don't have an M: on your machine it just ignores this and steps on to look in other places but if there is either a network M: or an inserted memory card appearing as M: or something then you hit this problem. It is not a problem in Studio as such.

If you load avr-gcc.exe into a program that can pull out the ASCII strings you will find, embedded in it:

m:/WinAVR
m:/WinAVR/bin/
m:/WinAVR/lib/gcc/
m:/WinAVR/libexec/gcc/
m:/WinAVR/share/locale
m:/WinAVR/share/locale
m:/WinAVR/share/locale

which I think was the directory structure on the machine where avr-gcc.exe was built in the first place.

Cliff

Ok, so I'm a day late. (There's a lot of posts to go through and I don't check this forum often).

Yes, Cliff is essentially correct. The only technical nit is that it's not where GCC is built, but where it is *installed* after it is built. That installation directory is specified when you configure GCC ("configuration" is the step before you actually build the software). That installation directory is hard-coded into the GCC executable as the place where GCC will look for other components (programs) that it will call on compile. If GCC does not find the components there, only then will it look on the PATH environment variable. This characteristic is due to the Unix nature of GCC, where it is expected that everyone builds GCC for themselves and it doesn't necessarily get redistributed. On Windows, however, it is common for the executable to be built once and then redistributed to various machines that may have different setups.

So, yes, this is a known issue. I submitted a bug report on it awhile back to the GCC team. No, AFAIK, nothing has been done on it. Yes, I do have an idea for a workaround, but it hasn't been tested yet. Yes, the reason why I haven't tested it yet, is because I haven't done a new WinAVR release. Yes, the reason why I haven't done a new WinAVR release yet, is because I've been incredibly busy with moving and a new job. Yes, some of you may already know where my new job is, for those of you who frequent the avr-gcc and avr-libc mailing lists. And for those of you who don't know, or anyone for that matter, please feel free to contact me at my (relatively) new place of employment:

eweddington@cso.atmel.com
Eric Weddington
Sr. Software Engineer
RF & Automotive Applications Group
Atmel Corp.
(Colorado Springs, CO, US)

And, yes, AFAIK, WinAVR will continue to exist (really, it's on my high priority TODO list to get out a new release, just after the current high priority task I'm working on...), and no, Atmel does not officially own WinAVR.

I hope that clears up a few things now.... :)

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

Well here's an idea which might help Jesper (and anyone else in this situation).

Using the 'dos' subst command, create a virtual m: drive pointing to the directory above your WinAVR directory.

GCC can then use the m: drive (and avoid working through the path environment variable), and when you plug in your usb drive, it will be forced up to the next available drive letter.

HTH.

Colin

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

EW wrote:
please feel free to contact me at my (relatively) new place of employment:

Sr. Software Engineer
Atmel Corp.


Just to say congratulations on the new appointment.

Cliff

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

Thanks for the info. I'll update the thread's title.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Found another bug (build 456).
When I start AVRStudio and open a project, the source windows that was open when I closed the project the last time is moved down and to the right (like when you open multiple windows in a MDI app in Windows). They're soon about to reach the edge, and I really wonder what will happen then ;-)
So, it seems the window positions is not restored correctly.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

The Breakpoint Option "Continue Execution after the Views have been
updated" does not work, even in the Simulator.

Martin

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

The AVR-GCC does not correctly define the -DF_CPU=xx as in the WinAVR Makefile

The frequency specified in "Project Options" in Hz should be passed with UL:

e.g. Frequence in Project Options: 4000000 hz
is passed to build window as:
-DF_CPU=4000000, but should be -DF_CPU=4000000UL

This is required to pass the frequency as a 32 bit value to the compiler

The only work-around is to edit F_CPU using Project Options -> Custom Options

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

pfleury wrote:
The AVR-GCC does not correctly define the -DF_CPU=xx as in the WinAVR Makefile

The frequency specified in "Project Options" in Hz should be passed with UL:

e.g. Frequence in Project Options: 4000000 hz
is passed to build window as:
-DF_CPU=4000000, but should be -DF_CPU=4000000UL

This is required to pass the frequency as a 32 bit value to the compiler

The only work-around is to edit F_CPU using Project Options -> Custom Options


According to the comments in the WINAVR makefile_template file:
Quote:
Do NOT tack on a 'UL' at the end, this will be done automatically to create a 32-bit value in your source code.

Don

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

donblake wrote:
According to the comments in the WINAVR makefile_template file:
Quote:
Do NOT tack on a 'UL' at the end, this will be done automatically to create a 32-bit value in your source code.

That's simply because MFile's makefile template defines the constant passed to the compiler as CDEFS = -DF_CPU=$(F_CPU)UL. This is the meaning of automatic...

Bye. Carlos.

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

carloslamas wrote:
That's simply because MFile's makefile template defines the constant passed to the compiler as CDEFS = -DF_CPU=$(F_CPU)UL.

Carlos, you are correct - I missed that.
pfleury wrote:
The AVR-GCC does not correctly define the -DF_CPU=xx as in the WinAVR Makefile

The frequency specified in "Project Options" in Hz should be passed with UL:


Based on what I learned from Carols' post, I agree.

Don

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

-projects don't autosave when buit anymore. Unless this is an option I had turned on in 4.11, I did not see it in the options of 4.12.

-labels can't be on the same line as .db (intended?)

-ADCSR was changed to ADCSRA for the tiny26 (intended?)

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

-sometimes when i come back from hibernate it says 'server is busy' and hogs up the cpu until i end program

-sometimes when i open a project the individual files are there in the tabs but not there in the workspace. Clicking on a tab does not bring up anything.

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

In the Memory Window Is is possible to preserve the memory type and the start address of the window.
I ahve three windows where I monitor memory contest . iteral ram, and twop external ram buffers.
The porblem is that AVRStudio does not preserve the m,emory type nor start address.
Can this be added please
Kind Regards
Ivan Vernot

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

outer_space wrote:
-projects don't autosave when buit anymore. Unless this is an option I had turned on in 4.11, I did not see it in the options of 4.12.

This is for me the most anoying bug, i lost half an hour searching why the latest software changes didn't work :-(

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

Cannot uninstall!!

After successfully using 4.12 (build 460) on two PCs, one with Windows XP Pro (not Service Pack 2) and one with Windows 2000, I installed it on a PC with Windows XP Pro Service Pack 2, IE version 6. I ran into problems with JTAGICE not being recognized (will post separately about these, when I get exact message wording) and attempted to uninstall.

When I try to uninstall (click the Remove button in Control Panel), the screen flashes and nothing else happens.

I tried uninstalling on my other PC with XP Pro and it started to uninstall properly (I responded "No" to confirmation).

One difference is that 4.12 is the first version loaded on the problem PC. On the others, I had previously loaded 4.11 and (contrary to Atmel's advice) simply installed 4.12 over that.

Any ideas?

Thanks in advance.
Michael Bate

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

A watch bug.

(maybay already mentioned before, I didn't follow this forum for a while, sorry if so)

When using a multidimension variable, like char i[2][2], the watch window doesn't show correct info, see attached image.

Jan Pieter de Ruiter

Attachment(s): 

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

With 4.11, after downloading the code, emulation was stopped at the begining of the program waiting for me to hit F5 to start. With 4.12 after downloading execution hits the ground running. Also the debug/reset function causes execution to restart, even if pressed AFTER hitting break. This is bad.
Work-around is to hit break and set a breakpoint at the first line in my program.

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

I made my own toolbar (Tools -> Customize... -> Toolbars -> New).
Next time I started AVRStudio 4.12 I had two of these own toolbars.
Then 3, then... AVRStudio didn't start anymore, just a window reporting an error.
So I downgraded back to 4.11 + sp3 (this is now second time).

Also commonly it was more like lottery what did the desktop look like after almost any operation.
(Yes, I noticed that this version has different priciple in storing desktop settings, but still...)
Once it looked like AVRStudio started, but every operation with mouse was directed to the
underlaying Windows desktop, and some desktop icons appeared thru holes in this "image"
of AVRStudio.

I don't complain, it's a free tool. I just hope it gets fixed, looks otherwise attractive.
I use Windows 2000 + SP4, P4 and Radeon 9200

Disclaimer
There is no warranty for this text.
I provide this text "as is" without warranty of any kind.
In no event will the writer, be liable to you for damages

Trademarks
Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
A list of Atmel's registered trademarks may be obtained from any publicly accessible patent database, subject to the limitations or restrictions of such databases, if any.

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

New AVR Studio update.

AVR Studio 4.12, Service Pack 1, build 461.
Get it here: http://www.atmel.no/beta_ware

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

Pages