why does program run with 5.0 but not with 5.1 ?

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

Hi,

I just installed AVR Studio 5.1 just to try it. Before I used the 5.0.1223. When I compile my project with that older version and upload to the AVR via JTAGICE mkII there is no problem, the program starts. When I open the same project with 5.1, compile and upload it onto the AVR nothing happens, the program doesn't run. As the Studio has become rather complex, I thought maybe someone experienced the same and can tell me what's the difference or what setting I have to change to make it run.
Thank you,
best regards

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

Quote:

When I open the same project with 5.1, compile and upload it onto the AVR nothing happens, the program doesn't run. As the Studio has become rather complex, I thought maybe someone experienced the same and can tell me what's the difference or what setting I have to change to make it run.

The two should work identically. Can you try compiling with AS5.0, but then use AS5.1 to upload the program to your device? That will rule out the IDE, and move the focus onto the toolchain differences between the two versions.

Also, what interface are you using to program the device? I've seen some project upgrades return the programming speed to the slowest speed possible, causing apparent failures when in reality it just took a minute to reprogram the device.

- Dean :twisted:

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

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

Hi,

I have the same problem as “mzeu”. From 5.0 it works fine to compile and run debug on the board, but with 5.1 it does not. In my case it never finish the init of the processor clock (the program seems to be downloaded and running correctly, but never passes that point). Is there any setting or something in 5.1 regarding the processor clock which needs to be specified?

I tried building with 5.0 and programming with 5.1, which worked fine (just downloading code, not debugging..).

I'm using an Xmega128A3.

// 128bits

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

I just did some tests (using JTAG by the way), the problem is that the JTAGICE mkII needs to be updated when using 5.1 . The upload of a 5.0 compiled file worked. Then I tried to verify that but now the ICE doesn't work at 5.0 anymore so I'll have to downgrade. So it seems to be the toolchain but I'm not sure if the JTAG firmware is good also.

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

Hi,

I made a small dummy code which I ran on 5.0 and 5.1:

static uint16_t j = 2;
	
for(uint16_t i = 0; i < 10; i++)
{
	j++;
}

The result:
AVR studio 5.0.1163: j = 12
AVR studio 5.1.208: j = 2

As far as I know, the projects are set up identically. I also noticed that debugging with 5.1 with code built on 5.0 works fine. So I guess the problem I see is not related to the JTAG ICE but rather the building.

Mzeu; which micro-controller do you use?
(Btw, I don't need to downgrade the JTAG ICE fw to run on 5.0)

// 128bits

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

Quote:

As far as I know, the projects are set up identically. I also noticed that debugging with 5.1 with code built on 5.0 works fine. So I guess the problem I see is not related to the JTAG ICE but rather the building.

IIRC the default optimization level was changed between the two, which could account for that - the optimizer can see that the loop has no side-effects (if you don't use "j" afterwards in a volatile context) and thus optimizes it out. Try building/debugging both on -O0.

- Dean :twisted:

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

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

Sorry, I should have explained myself better. In both cases –O0 is used, and I actually set one global variable (used in the project) to j later on, just to be sure.

The option strings look like this:

5.1:
-funsigned-char -funsigned-bitfields -D__DEBUG__ -DF_CPU=16000000UL -I"../../../../proj_lib" -I"../../../../xmega_lib" -O0 -fpack-struct -fshort-enums -g2 -Wall -c -std=gnu99 -MD -MP -MF "$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" -mmcu=($DEVICE)

5.0:
-funsigned-char -funsigned-bitfields -D__DEBUG__ -DF_CPU=16000000UL -I"../../../../proj_lib" -I"../../../../xmega_lib" -O0 -fpack-struct -fshort-enums -g2 -Wall -c -std=gnu99 -mmcu=atxmega128a3

Is there any way to be sure of what AVR studio thinks $DEVICE is? Under the device tab it states ATxmega128A3, but is there anywhere else to double check this?

//128bits

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

Quote:
Is there any way to be sure of what AVR studio thinks $DEVICE is? Under the device tab it states ATxmega128A3, but is there anywhere else to double check this?

After performing the "Build solution" look for the messages logged in your Output Window [View -> Output]

Regards,
Deena

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

Thanks!
atxmega128a3 it is, so it seems correct.

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

Could you please verify your linker options for 5.0 and 5.1?

If possible PM me the project files of 5.0(*.avrgccproj) and 5.1(*.cproj) to see if there are any configuration differences.

Regards,
Deena

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

Quote:

The result:
AVR studio 5.0.1163: j = 12
AVR studio 5.1.208: j = 2


How are you observing 'j'? If you switch to a mixed C+asm view and determine which register pair 'j' has been cached into then is that incremented?

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

Sounds similar to the following issue.

http://avrstudio5.wordpress.com/2011/12/16/unable-to-program-the-target-with-newly-created-projects-example-projects-in-studio-5-0-rtm/

* Try deleting "ProjectsTemplateCache" and "~PC" directory from Atmel Studio installed directory and from "[Percentage Symbol]appdata[Percentage Symbol]\Atmel\AVRStudio51\5.1"

:)

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

Quote:
How are you observing 'j'? If you switch to a mixed C+asm view and determine which register pair 'j' has been cached into then is that incremented?

I took a look at the assembler code yesterday. The disassembly shows the same result for 5.0 and 5.1, but for 5.1 the last branch evaluates to not do the jump in the for-loop.

5.1:

00008CE7  PUSH R29		Push register on stack 
00008CE8  PUSH R28		Push register on stack 
00008CE9  PUSH R0		Push register on stack 
00008CEA  PUSH R0		Push register on stack 
00008CEB  IN R28,0x3D		In from I/O location 
00008CEC  IN R29,0x3E		In from I/O location 
	for(uint16_t i = 0; i < 10; i++)
00008CED  STD Y+1,R1		Store indirect with displacement 
00008CEE  STD Y+2,R1		Store indirect with displacement 
00008CEF  RJMP PC+0x000F		Relative jump 
		j++;
00008CF0  LDS R24,0x27A5		Load direct from data space 
00008CF2  LDS R25,0x27A6		Load direct from data space 
00008CF4  ADIW R24,0x01		Add immediate to word 
00008CF5  STS 0x27A5,R24		Store direct to data space 
00008CF7  STS 0x27A6,R25		Store direct to data space 
	for(uint16_t i = 0; i < 10; i++)
00008CF9  LDD R24,Y+1		Load indirect with displacement 
00008CFA  LDD R25,Y+2		Load indirect with displacement 
00008CFB  ADIW R24,0x01		Add immediate to word 
00008CFC  STD Y+1,R24		Store indirect with displacement 
00008CFD  STD Y+2,R25		Store indirect with displacement 
	for(uint16_t i = 0; i < 10; i++)
00008CFE  LDD R24,Y+1		Load indirect with displacement 
00008CFF  LDD R25,Y+2		Load indirect with displacement 
00008D00  CPI R24,0x0A		Compare with immediate 
00008D01  CPC R25,R1		Compare with carry 
00008D02  BRCS PC-0x12		Branch if carry set 

5.0:

00008CE7  PUSH R29		Push register on stack 
00008CE8  PUSH R28		Push register on stack 
00008CE9  PUSH R0		Push register on stack 
00008CEA  PUSH R0		Push register on stack 
00008CEB  IN R28,0x3D		In from I/O location 
00008CEC  IN R29,0x3E		In from I/O location 
	for(uint16_t i = 0; i < 10; i++)
00008CED  STD Y+1,R1		Store indirect with displacement 
00008CEE  STD Y+2,R1		Store indirect with displacement 
00008CEF  RJMP PC+0x000F		Relative jump 
		j++;
00008CF0  LDS R24,0x27A5		Load direct from data space 
00008CF2  LDS R25,0x27A6		Load direct from data space 
00008CF4  ADIW R24,0x01		Add immediate to word 
00008CF5  STS 0x27A5,R24		Store direct to data space 
00008CF7  STS 0x27A6,R25		Store direct to data space 
	for(uint16_t i = 0; i < 10; i++)
00008CF9  LDD R24,Y+1		Load indirect with displacement 
00008CFA  LDD R25,Y+2		Load indirect with displacement 
00008CFB  ADIW R24,0x01		Add immediate to word 
00008CFC  STD Y+1,R24		Store indirect with displacement 
00008CFD  STD Y+2,R25		Store indirect with displacement 
	for(uint16_t i = 0; i < 10; i++)
00008CFE  LDD R24,Y+1		Load indirect with displacement 
00008CFF  LDD R25,Y+2		Load indirect with displacement 
00008D00  CPI R24,0x0A		Compare with immediate 
00008D01  CPC R25,R1		Compare with carry 
00008D02  BRCS PC-0x12		Branch if carry set

Thanks for the tips from “tsgd84” and “mailtosarathy”! I will try these when I get my JTAG ICE back on Monday. I’ll report back my findings.

//128bits

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

Quote:

The disassembly shows the same result for 5.0 and 5.1, but for 5.1 the last branch evaluates to not do the jump in the for-loop.

Eh? As you say the asm is exactly the same. How could the CPU possibly behave differently? As I asked - what happens if you follow the actual contents of 0x27A5/0x27A6 where 'j' is clearly being stored?

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

All,

After a tip from ” tsgd84” I removed the (default in 5.1?) linker setting “stack=0x2000", which seem to solved the problem.

Thank you a lot!

// 128bits

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

There seems to be an issue in opening projects created in 5.0 and are opened in 5.1

Though the stack initial address is not enabled in 5.0, when converting the 5.0 project to 5.1 project, by mistake the stack initial address is getting enabled and hence the linker takes the additional option to build the output.

Quote:
After a tip from ” tsgd84” I removed the (default in 5.1?) linker setting “stack=0x2000", which seem to solved the problem.

This option is not by default in 5.1, there will not be any such option added by default if new project is created in 5.1

Regards,
Deena

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

Wow, I just got bitten by this, wasted a couple of hours before I decided to look on the forum!

John

Four legs good, two legs bad, three legs stable.

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

In case anyone's interested, this seems to happen with the XMega256A3 as well, except it's “stack=0x4000".
I wasted another hour or so on this!
How stupid am I?

Four legs good, two legs bad, three legs stable.