JFYI: AVR Studio 4.13, build 528 (Release) announced

Go To Last Post

21 posts / 0 new

Author

Message

skleroz

Level: Wannabe

Joined: Sun. Dec 5, 2004

Posts: 65 View posts

Posted by skleroz: Wed. Feb 28, 2007 - 06:24 PM

http://www.atmel.no/beta_ware/

[UPD]"The requested URL /beta_ware/release413.txt was not found on this server" :( - fixed now

Also availiable at http://www.atmel.com/dyn/product...

Release Notes - AVR Studio 4.13 (02/2007)
-----------------------------------------

This release contains complete support for all the latest AVR devices and tools. New features are added and bugfixes have been done.

Part support:
-------------

AT90USB646 (JTAGICE MKII, STK500/525, AVRISP MKII, SIMULATOR, AVRASMII,DRAGON)
AT90USB647 (JTAGICE MKII, STK500/525, AVRISP MKII, SIMULATOR, AVRASMII,DRAGON)
AT90USB162 (JTAGICE MKII, STK500/526, AVRISP MKII, SIMULATOR, AVRASMII)
ATmega88P/168P (JTAGICE MKII, STK500, AVRISP MKII, SIMULATOR, AVRASMII,DRAGON)

Features:
---------

*Complete Dragon device support. Please read the AVR Dragon user guide for all the details.

*New I/O view and processor view prepared for the coming and more advanced devices. With 3 modes for viewing different I/O modules and registers, the user can easier and faster debug complex peripheral configurations. The old tree view is still available as one of the 3 view modes. Read more about the new IO View and the new Processor view in the AVR Studio user guide.

*New technical preview of a simulator based on automatic conversion of proper chip models. When using this method we can create more reliable simulator models with more complete peripheral support. This is still under development and we want feedback both on wanted features and usability. Read more about the simulator V2 preview in the AVR Studio user guide.

*AVR Studio is now fully compatible with the latest version of WinAVR. The former 64K limit on flash size when using WinAVR/GCC compiler have been fixed. It requires that you use the latest WinAVR release (after 2007-01-02)

*New USB driver from Jungo(WinDriver USB v8.1) that support both 32 bit and 64 bit Windows XP. Please note that Vista 64 bit is not supported yet, but will be available in a service pack when ready.

*AVR Studio is now fully compatible with Microsoft Windows Vista(32 bit).

Bug-fixes:
----------

Fixes done in beta period:
5568: Corrected installation of 64-bit Windows XP USB driver.
5414: Fixed opening of existing GCC projects. Settings are now restored properly.
5399: Fixed character display in watch window.
5399: Added shortcuts to build menu.
5293: The command next breakpoint added to debug menu.
5469: Corrected value editing in I/O registers.
5387: Processor view and I/O view is now restored correctly when switching between edit and debug mode.
5487: Fixed a crash when clicking in the register pane when empty.
4759: Problem with dual monitors is now fixed.

Various:
202: Enhanced the error message generated if an automatic firmware update fails for STK500/AVRISP. The user is now refered to the proper help documentation.
4087: AVR Studio 4.13 now installs the USB drivers by default.
4430: The JTAGICE mkII and AVR Dragon drivers required the document element to be the first node in the XML part files (processing instructions, comments etc was not accepted). This has been fixed.
4736: The simulator could start generate Stack Overflow messages for a program using IJMP instead of RET/IRET to return from a function. This has been fixed.
4835: The same error message was generated when an operation in the STK500 programming dialog failed, no matter what type of failure occurredd. This has been enhanced.
4931: The error message displayed when the JTAGICE mkII or AVR Dragon connected to a device with an unknown signature was confusing, and has been enhanced in AVR Studio 4.13.
4988: If one single part descriptor file contained an error (even though all other part files were correct), the JTAGICE mkII and AVR Dragon would list no devices in the Select Device and Platform dialog. This has been fixed.
5201: The JTAGICE mkII option "Preserve EEPROM contents when reprogramming device" would override the users fuse selection without notifying the user. This could cause the EEPROM of the device to be erased silently. This has been changed so that if the "Preserve EEPROM" fuse of the device is set, the user is asked before the EEPROM is erased.
5316: In some occasions, the value of sub elements of expanded data types in the watch window could not be edited. This has been fixed.

WinAVR support and GCC plug-in:
500: Moved source file in gcc-plugin. If a file is reported as missing when starting the plugin, an item is added to this file's context menu in the project tree.
641: Setting for optimization not remembered when changing settings in a different tab afterwards.
The scheme for OK/Cancel functionality in the property pages has been completely rewritten, and options that have dependencies across pages are remembered when switching from one page to another.
3999: dep directory is deleted on each build. Sufficient to delete only the files below
4116: Object files are not properly removed when removing them in library property page
4117: Build fails when using old WinAVR distribution. Older cygwin make versions have problems with interpreting '\'.
4381: Symbols are not passed to the assembler. Symbols defined with -D will now be passed on to the assembly rules in the generated makefile.
4260: Build hangs, seemingly because of unix-style separators in .d file. This is fixed.
4264: avr-size is now used if WinAVR release 20060125 or better is detected.
4620: Wrong error message when trying to rename/create file with illegal character. This is now fixed.
4664: The project tree is now sorted again when file 'Show File Paths' are chosen from the context menu.
5056: Project Options->device edit/list box is case sensitive. This is now fixed.
5057: Part support list are now synchronised with the latest WinaAVR release.
5065: Inconsistent crash behaviour in 'Memory Segments' control. This is now fixed.

Elf/Dwarf parser:
3439: Problem watching typedef const enum. This type was not evaluated all the way, and resulted in an error. These types are now evaluated correctly.
4534: AVR Studio claims "The contents of the object file exceeds the maximum program memory of the device"
The elf parser had an erroneous algorithm for computing the last program memory address. This is now fixed.
4907: Parser doesn't handle zero-sized section of particular types. Segments of size 0 are now ignored when parsing the object file.
4688: The Elf/dwarf parser did assume SRAM location for all variables. Newer versions of avr-gcc can be configured to output variable locations as absolute addresses (including the avr-specific offsets for eeprom and progmem). This enables the parser to discern between these variables.
4815: The elf/dwarf parser was updated to handle objects with 32 bit program memory address space.
5044: uint8_t was in some cases laid out as the innermost type. Code has been added to the parser to recognize all types in as basic types.
5202: Fails to load object files without .data or .text section

Note:
Windows 95 is not supported from version 4.12 Service pack 3.

Tags:

Tools, Atmel Studio (AVR-related), AT90USB162, AT90USB646, AT90USB647, ATmega8, ATmega88, ATmega88P

Last Edited: Fri. Mar 2, 2007 - 06:35 AM

pop48m

Level: Wannabe

Joined: Thu. Nov 17, 2005

Posts: 97 View posts

Posted by pop48m: Thu. Mar 1, 2007 - 01:06 AM

skleroz wrote:

http://www.atmel.no/beta_ware/

It's available now.

AVR Studio 4.13, build 528 (Release)
Download 75 MB Latest update February 28, 2007

Level: Moderator

Joined: Wed. Mar 28, 2001

Posts: 29968 View posts

Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)

Posted by js: Thu. Mar 1, 2007 - 01:24 AM

Quote:

Download 75 MB

eh (as the Canadian say) I'll wait, someone else can be the guinea pig this time :) this is almost 1/4 of my peak d/l allowance so I will need to d/l on off peak time from 12:00 - 6:00 am :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Mike B

Level: Raving Lunatic

Joined: Tue. Jun 22, 2004

Posts: 3836 View posts

Location: South West Utah, USA

Posted by Mike B: Thu. Mar 1, 2007 - 02:13 AM

pop48m wrote:

It's available now.

It is the release notes that skleroz cannot find. I cannot find them either.

Level: Raving Lunatic

Joined: Thu. Mar 1, 2001

Posts: 4914 View posts

Location: Rocky Mountains

Posted by EW: Thu. Mar 1, 2007 - 03:04 AM

Problem noted and will be fixed soon.

Eric Weddington
www.linkedin.com/in/ericweddington/

lfmorrison

Level: Raving Lunatic

Joined: Wed. Dec 8, 2004

Posts: 4643 View posts

Location: Nova Scotia, Canada

Posted by lfmorrison: Thu. Mar 1, 2007 - 03:36 AM

Canadians typically put the "eh" at the end of the sentence, thus turning it into a question, eh?

Level: Moderator

Joined: Wed. Mar 28, 2001

Posts: 29968 View posts

Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)

Posted by js: Thu. Mar 1, 2007 - 07:53 AM

Yes but my 'eh' is with an Italo Australian accent, more like a Simpsons 'eh' :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

RayKAvr

Level: Hangaround

Joined: Tue. Nov 29, 2005

Posts: 105 View posts

Posted by RayKAvr: Thu. Mar 1, 2007 - 07:40 PM

Thanks for pointing out the new release.

One suggestion to developers. If it hasn't already been done, please test all AVRStudio releases from now on to make sure that everything co-exists nicely with AVR32 tools on the same machine. I haven't found any problems. Am just suggesting that it would be nice if the development team tests it and makes a note in the release note that it's ok to have both on one computer.
Thanks!

Level: Raving Lunatic

Joined: Thu. Mar 1, 2001

Posts: 4914 View posts

Location: Rocky Mountains

Posted by EW: Sat. Mar 3, 2007 - 04:21 AM

The issue (about toolchain coexistence) is known and will be worked in the immediate future. At this point, I can't guarantee that there won't be problems with having the two GCC toolchains coexist, but we're committed to getting things worked out. If there are no issues currently, then that's good, but probably accidental. But in the future there will be a conscious effort to making sure that everything plays well together.

Eric Weddington
www.linkedin.com/in/ericweddington/

port513

Level: Rookie

Joined: Mon. Feb 19, 2007

Posts: 44 View posts

#10

Posted by port513: Sat. Mar 3, 2007 - 10:30 AM

I still have a maximize bug when I run some programs in the tray. If I close them and restart AVR Studio it's maximized as it should.

This is the only software on my computer that behaves like this.

/Henke

daqq

Level: Raving Lunatic

Joined: Mon. Dec 15, 2003

Posts: 4281 View posts

Location: Slovakia, Bratislava

#11

Posted by daqq: Sat. Mar 3, 2007 - 12:46 PM

When is it gonna get non-beta?

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

RayKAvr

Level: Hangaround

Joined: Tue. Nov 29, 2005

Posts: 105 View posts

#12

Posted by RayKAvr: Sat. Mar 3, 2007 - 03:53 PM

EW, thanks for reading my comment about testing AVR and AVR32 tool co-existence on a single computer.

Also thanks to the development team for fixing any issues that might have been there with opening old GCC project files. Mine are now all re-created from scratch so I can't test it.

Question: did you happen to notice one of my earlier posts about the AVRStudio beta crashing or hanging when it comes back from computer in sleep mode (with the Dragon programming dialog open)?

I disabled my power down settings so the computer never goes into sleep mode unless I push the button, but with more people doing development on laptops this could be encountered more often.

Level: Raving Lunatic

Joined: Thu. Mar 1, 2001

Posts: 4914 View posts

Location: Rocky Mountains

#13

Posted by EW: Sun. Mar 4, 2007 - 08:05 PM

Hi RayKAVR,

Sorry, I don't recall reading that particular post. It's difficult to read everything here on AVR Freaks. ;)

The best thing to do is to send an email to avrbeta@atmel.com if you discover any problems or issues. That way it will be sure to be tracked.

Thanks
Eric Weddington

Eric Weddington
www.linkedin.com/in/ericweddington/

evelynsabbag

Level: New Member

Joined: Wed. Feb 28, 2007

Posts: 13 View posts

Location: Deerfield Beach, FL

#14

Posted by evelynsabbag: Mon. Mar 5, 2007 - 10:20 PM

1. I've installed AVR Studio 4 version 4.13, Build 528 and the application becomes unresponsive, typically after a build, but not always. I believe I installed all the patches mentioned in the various posts; are there any less obvious ones I should know about?

2. Also, how does the AVR Studio/STK500/STK503 interface handle extended addressing in the hex files? My addresses for the bootloader are being truncated at 0xE000, instead of being put at 0x3E000. A section from my hex code is given below. The AVR programs this code at 0xE000, which causes a lot of havoc. I verified where the code was being programmed by doing a read of the FLASH. More is not always better :?

:020000023000CC
:10E000000D9472F00D948FF00D948FF00D948FF0AD
:10E010000D948FF00D948FF00D948FF00D948FF080

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101080 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#15

Posted by clawson: Tue. Mar 6, 2007 - 11:36 AM

2) has nothing to do with Studio does it?? That's a function of the WinAVR compiler/linker - or are you suggesting that the auto Makefile that studio builds for you is not behaving correctly?

evelynsabbag

Level: New Member

Joined: Wed. Feb 28, 2007

Posts: 13 View posts

Location: Deerfield Beach, FL

#16

Posted by evelynsabbag: Tue. Mar 6, 2007 - 02:52 PM

Studio is working fine; as the code shows, it is setting up the segment addresses as per Intel Hex specifications. The problem is when I try to download the file to the STK500/STK503. The serial programming interface from Studio to the development board appears to be ignoring the segment address in the first line and only programs code starting at 0xE000. My main question is how do I get the programming function to understand this is a segmented address? Or will it? I have searched all the forums, manuals and drop down options and can't see anything that explicitly allows programming beyond 64k of memory.

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101080 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#17

Posted by clawson: Tue. Mar 6, 2007 - 03:24 PM

I just tried recreating your problem by using the LDFLAGS setting you gave previously and building for a Mega2560. The hex file I end up with starts:

:020000023000CC
:10E000000D9474F00D9491F00D9491F00D9491F0A5
:10E010000D9491F00D9491F00D9491F00D9491F078

Notice the type 02 record at the very top? That's key I think.

If you think about it, Intel Hex only reserves 4 characters for the address field (the E000 and E010 in the type 00 records above). So that could only ever address 64KiB of data. The way Intel Hex gets orund this is with the 02 type "Extended Segment Base Address" record which allows the 64KiB to be offset to some other 64KiB section besides the first one.
So that 02 record has a USBA value of 3000. Which is what will offset the E000, E010 data to 3E000, 3E010, etc.

Or are you saying that Studio is ignoring the type 02 record and just programming to E000 anyway?

More about Intel Hex here: http://pages.interlog.com/~speff...

Cliff

evelynsabbag

Level: New Member

Joined: Wed. Feb 28, 2007

Posts: 13 View posts

Location: Deerfield Beach, FL

#18

Posted by evelynsabbag: Tue. Mar 6, 2007 - 03:28 PM

Thank you for rewording my message; I believe we are now on the same page.

Quote:

Or are you saying that Studio is ignoring the type 02 record and just programming to E000 anyway?

Yes, that is exactly the problem. Any work arounds or switches I'm missing?

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101080 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#19

Posted by clawson: Tue. Mar 6, 2007 - 03:34 PM

If you really think that then email avrbeta@atmel.com with a concise description of the problem and a set of Makefiles to create it.

But how do you *know* that the file with that 02 record is going to E000 and not 3E000 ?

Cliff

evelynsabbag

Level: New Member

Joined: Wed. Feb 28, 2007

Posts: 13 View posts

Location: Deerfield Beach, FL

#20

Posted by evelynsabbag: Tue. Mar 6, 2007 - 03:47 PM

I can send the makefile, but I don't believe that's the issue as the hex file seems fine--as we've both confirmed. The reason I believe the programmer is the issue, is because I read the Flash memory and saw the code residing at 0xE000, not 0x3E000.

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101080 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#21

Posted by clawson: Tue. Mar 6, 2007 - 03:50 PM

What do you mean by "saw the code residing at 0xE000"? Are you suggesting that the tool you use to read, rather than write the hex did no generate an 02 record - maybe THAT is the only fault here and it really does reside at 3E000 in the device?

Let's face it that Mega128 is as old as the hills and Studio has presumably faced this >64KiB issue for that for quite some time - unless this is newly broken in the latest Studio?

Cliff

Jump To

Search form

JFYI: AVR Studio 4.13, build 528 (Release) announced

Tags: