Xmega stability?

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

I am getting random jumps to high memory and thus simulated resets using ATxmega256A3. Please note that I am NOT using EEPROM writes when this happens and the only interrupt is a RTC second counter.

Additionally I have been using the xmegas for over a year now, but this is first time I have had code that passed the 64K boundry.

Also adding a printf() in main seems to mask the issue. Also if I drop clock rate to 2Mhz from 32Mhz it seems to fix or mask issue.

I have checked power several times and have plenty of decoupling, at each power pin. Additionally I have checked for stack overflow by writting known data at bottom of stack as well as monitoring stack pointer location.

I have also found that avr-gcc set RAMPZ but did not reset it, so I have done that manually and still have problems.

Thus I was wondering if anyone else knew of any stability issues besides the ones in errata?

Thanks
Trampas

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

Haven't heard of anything like that. Do you want to post your problem hex file? Maybe we could try running it for you if you tell us what to look for.

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

I would post hex file but it is 80K and dependent on external hardware and company I work for would not be happy. The hardware is external flash through SPI, nothing that should cause a crash.

So far I have nailed down that the interrupts still trigger after jump beyond code. Thus I can detect when it happens but not much luck in diagnosing.

Thanks
Trampas

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

"After jump beyond code" strongly suggests over-run stack. This can happen when an ISR return address gets pushed onto the stack, then the stack gets messed with by data from inside the ISR that over-laps the stack. This can also happen with ordinary functions. How full is your data space?

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

I put in magic number in upper memory to monitor stack and actually put in an ISR checks to monitor stack remaining.

What I have found is that:
#1 RAMPZ is not set to zero using GCC after data section is copied to SRAM. However this did not cause a problem
#2 if I set clock rate down to 2MHz problem appears to go away.
#3 Disabling all interrupts has no effect.
#4 power supply is rock solid, USB driving a 3.3V LDO with BOD set at 2.9V.

I can add code and problem goes away, remove code and problem goes away. I remove a delay_ms(1) line that is never called in code and problem goes away.

Thus it is looking like the processor is not stable at 32Mhz, might be a problem with reading code from flash, ie wait states?

Thanks
Trampas

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

Well since the F_CPU symbol is used to set the cycles delay in the delay_ms() I figured it would be good to leave this symbol at 32Mhz but set clock to 2Mhz this way the code stays the same as much as possible. The results is I still have the reboot problem.

Trampas

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

tstern wrote:
thus simulated resets

If the problem is due to using external memory, Note that AVRStudio4 simulator does not support external RAM for XMEGA.

Atmel support:

Quote:
Dear Customer,

Unfortunately External RAM support is not available yet in simulator.

Ozhan KD
Knowledge is POWER

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

By simulated resets what I am referring to is the code jumps above the code space and then starts executing the code as NOPs until the PC overflows and jumps back to address 0x0000 at which point the software appears to have just gotten a reset. I refered to it as a simulated reset as that it does not reset the registers to default values.

Trampas

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

Are you using internal RC or 16Mhz crystal?

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

I have been using the RC clock for all the testing. I have been posting some updates on the AVR-GCC forum as well but basically to recap.

The problem occurs with 192A3 as well.

The problem does not occur when we move the code 0x0100 bytes higher in memory. But this might be masking problem, ie problem has not occur yet.

The code with problems is executed several times before failing, thus code appears to be good.

The problem is not a stack overflow.

The problem only occurs when code is located above 64K, ie removing dead code and brining footprint under 64K allows code to work. Thus again proving the problem is not the code or stack overflow. But could be compiler addressing bug. However moving the code high in memory works thus it kind of eliminates compiler addressing bug (not completely but combined with code running several times before failing does).

The problem does not occur when single stepping through code using AVR studio. Thus removing compiler and code from problem space.

The problem is not with EEPROM as we are not writting to EEPROM in the code.

The problem is not interrupts as all interrupts are disabled.

The problem is not power supply as it was tried with external bench top supply.

The problem occurs with 2Mhz RC and 32Mhz RC.

All data is currently pointing to a problem with the flash memory above 64K on the chip. Specifically maybe a wait state and bad reads from flash when running full speed with pipeline.

I have been asked not to spend more time on the problem from a company perspective and we are currently looking at disqualifying the xmega from future designs. This is a shame as I really like the xmega and we have lots of library code for the processor now, but we have lost confidence in the parts.

Since I do like the parts if anyone knows of anything to try please let me know and I will try it on my own time.

Trampas

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

Again, code normally only lands out side of code space if the stack is trashed. I would suspect that the business about clock is mostly bogus - maybe at higher clock rates, the stack does not get a chance to get back to a "normal" level before some interrupt hits, pushing it into working RAM space. This could particularly be the case if there are multiple interrupt priority levels.

Since you say that this happens with interrupts disabled, then look at what happens with normal function calls. Try filling the SRAM space some marker value, then watch what happens as code progresses. I think you will find that when the PC lands in no-mans land, the markers will be all gone.

I think you REALLY need to address the cause of the incorrect code execution rather than fixating on the clock and possible "instability".

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Jim,

Thanks I did this check and the stack used from 0x5FFF to 0x5CB4. The unused stack space is 0x5BC4 to 0x38d4 (which includes the heap space which I don't use).

Thus I also did a test where I montior the stack pointer in an ISR a 1000 times a second and it does not over flow. Along with monitoring the stack pointer in the ISR I also wrote 0xdeadbeef to *(heap+512) and verified it never changed. Of course once I did this with interrupts on, but the code has same roll over behavior with/without interrupts.

Again I appreciate the suggestion and the stack was my first thoughts as I have seen that problem 100's of times.

I would appreciate any other suggestion people have!

I have thought about hacking GCC such that I can grab the return address in the GPIO0-GPIO2 registers at start of every function then print out the return address. I have thought about the same thing before every RET instruction by triggering a software interrupt just before RET.

Trampas

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

Right now I am setting up a dumb program that has code located in high memory that just increments a number and prints out the result.

However this program has yet to crash but I will let run overnight.

Thanks
Trampas

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

For those who are interested here is the stack checking code:

extern void * __heap_start;
#define PTR_HEAP_START (uint32_t *)((&__heap_start))

//Then inside main I do the following... 
if (RST.STATUS==0) //this happens when PC rolls over if was reset below. 
	{
		//we had code wrap around
		uint32_t i;
		uint8_t *ptr;
		ptr=PTR_HEAP_START;

		while((ptr+8)

Trampas

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

Quote:
#1 RAMPZ is not set to zero using GCC after data section is copied to SRAM. However this did not cause a problem

Since you have no EBI, and data memory is less than 64K, you are not using RAMPZ. You may be using it if using SPM or LPM though.

Are you sure you are jumping somewhere above the top of your code? Could you be jumping to 0x0000? If you are jumping above your code, is it somewhere above or below 128K? (The PC is word addressed, not byte addressed)

Since IO registers are accessible via ST*/LD*, could your code possibly be clobbering SPL/SPH before a RET/IRET? Could it be writing into the stack (as opposed to a stack overflow, which was my first thought)?

GCC spits out different code depending on which optimization level is used. Can you lower the optimization level? This may only mask the problem, but might get you closer to solving it. GCC has had bugs when using the xmega. What version of GCC are you using? WinAVR? Linux?

Are you using DMA?

I had a problem with similar symptoms on an ATxmega128a1. The problem was masked if I changed/moved code around. It turned out to be a DMA issue. Another similar problem was a corrupted pointer that wrote into IO memory. This was an atomic access issue.

Quote:
The problem occurs with 2Mhz RC and 32Mhz RC.

You mentioned before that the problem went away at 2MHz. Has this changed, or were you not using the 2MHz RC when the problem seemed to go away?

Since you are not calling or jumping to code beyond 128K, you should not need the EIND register. By chance, does GCC output any EICALL/EIJMP instructions?

https://www.mattairtech.com/
ARM Cortex M and XMEGA development boards / Gentoo Linux

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

I have bootloader running in the bootloader section thus I know that code has gone to upper memory when the bootloader has been called. Additionally sometimes it jumps into some test code that I never call in the main program.

I could be clobbering the stack pointer but the problem is very repeatable when the code is over 64k, if I use the dead code removable, ie placing each function in unique section and having linker remove the unused sections the code appears to work perfect. Thus I am assuming the code generated in both cases are the same except for the jmp/call addresses. Therefore if I was clobbering the stack pointer I would assume it would happen in both cases.

When I compile the code using F_CPU==2Mhz the problem went away. After thinking about it for awhile I realized the code was different as I use __delay_ms() and __delay_us() in spin loops. Thus I compiled the code using F_CPU=32Mhz but set the clock to 2Mhz to have the same code run (except for UART which had prescaler changed for 2Mhz). Doing this code does have the problem thus it is not a clock problem.

I am not using any DMA function, and I have verified it does the problem without ISR.

I am using WinAVR from Jan 2010. Which I understand has some bugs, and the libc is old. I was planning on building the tool chain from sources this weekend.

I would accept a compiler bug for this problem. However I loaded the code into AVR studio and was stepping through the code. I found that I was getting a character out UARTC0 when I called a uint32_t divide. Thus I manually line by line stepped through the assembly and found no problem. However when it runs at speed it puts out the character. For example I set a break point to jump out of the loop in the divide and in appears that inside the divide the character appears. Note my code is not using interrupts and the character coming out is not one I have sent to UART thus I don't think it is a delay on the UART peripheral. When this character appears I have noticed that the code crashes shortly there after, usually when I am calling puts().

GCC in the libc for the stdio, ie printf and puts, does use the EICALL due to pointers to functions and I use pointers to functions in my code. I had thought the EIND might be a problem as it is not set until I realized the pointers are word pointers.

I also have created a program which I manually set linker to put in upper 64K, this is really simple printf() type of program and it has ran over night with out crashing. Thus this test is leading me to believe it is not as simple as flash being read wrong.

One idea I had is if interrupts are called immediately I could manually replace the RET instructions with a software triggered interrupt. Then in the interrupt I could log the return address on the stack and actually call the RET from in the interrupt. However it would require that the ISR be called immediately, else I would have to hack GCC to add NOPs after RETs.

Thanks again for the help!
Trampas

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

WinAVR 20100110 uses avr-libc 1.6.7 which is really out of date. There are numerous fixes up through the latest version. Definitely try the latest version before continuing.

https://www.mattairtech.com/
ARM Cortex M and XMEGA development boards / Gentoo Linux

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

I have downloaded and install AVR Studio 5.0 which includes avr-gcc using GCC 4.5.1. I am not sure about which libc is included but so far the code works!

Thanks
Trampas

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

Cool! Maybe version 1.7.1. Your avr-libc also has patches applied that are not in the standard avr-libc release.

https://www.mattairtech.com/
ARM Cortex M and XMEGA development boards / Gentoo Linux

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

I'm working on several projects using Atmel's MAC package. While I did not notice the kind of problems that are mentioned in this thread (reseting code) the at86rf212 did NOT work correctly when we used the MAC code with the xmega256a3 processor (GCC). As our code size was still less than 128K and data space was also less than what was available in the xmega128a3 processor we tried that. After rebuilding the code making no changes except to change the cpu define the application worked correctly. I know that GCC has had to resort to some 'hacks' to support code size above 128K but I have not been able to figure out why the Atmel MAC code breaks down when compiled by GCC for the xmega256 core. The software failure caused the radio to exhibit a high error rate during receive, I do not know if this was due to errors in setting the transceiver registers or in reading back from them. It may have also been taking wrong branches in the TAL code.

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

I stumbled across a similar problem with RAMPZ set to 1. Target is a xmega 128A1, toolchain is AVR Studio 5. When footprint crosses the 64K boundary, RAMPZ is 1 on entry of main. I manually cleared the register and firmware seems to work...

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

th.rahn wrote:
I stumbled across a similar problem with RAMPZ set to 1. Target is a xmega 128A1, toolchain is AVR Studio 5. When footprint crosses the 64K boundary, RAMPZ is 1 on entry of main. I manually cleared the register and firmware seems to work...

IIRC RAMPZ is used to access constants from program memory. The compiler should generate code to set it as required. So this doesn't make much sense.

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

Quote:

IIRC RAMPZ is used to access constants from program memory. The compiler should generate code to set it as required. So this doesn't make much sense.

Presumably it had it set during the .data loop in the CRT and never reset it?

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

clawson wrote:
Quote:

IIRC RAMPZ is used to access constants from program memory. The compiler should generate code to set it as required. So this doesn't make much sense.

Presumably it had it set during the .data loop in the CRT and never reset it?

That would be a bug in the compiler / library. I had the problem going from an xmega128 to xmega256. Code never exceeded 64k bytes. We are now using the xmega128 and gave up on the 256 (for now) as it seems unlikely our application will outgrow the 128.

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

The current HEAD of avr-libc does not appear to have such a problem:

http://svn.savannah.nongnu.org/v...


#if BIG_CODE
	/* Only for >64K devices with RAMPZ, replaces the default code
	   provided by libgcc.S which is only linked in if necessary.  */

	.section .init4,"ax",@progbits
	.global __do_copy_data
__do_copy_data:
	ldi	r17, hi8(__data_end)
	ldi	r26, lo8(__data_start)
	ldi	r27, hi8(__data_start)
	ldi	r30, lo8(__data_load_start)
	ldi	r31, hi8(__data_load_start)

	/* On the enhanced core, "elpm" with post-increment updates RAMPZ
	   automatically.  Otherwise we have to handle it ourselves.  */

#ifdef __AVR_ENHANCED__
	ldi	r16, hh8(__data_load_start)
#else
	ldi	r16, hh8(__data_load_start - 0x10000)
.L__do_copy_data_carry:
	inc	r16
#endif
	out	AVR_RAMPZ_ADDR, r16
	rjmp	.L__do_copy_data_start
.L__do_copy_data_loop:
#ifdef __AVR_ENHANCED__
	elpm	r0, Z+
#else
	elpm
#endif
	st	X+, r0
#ifndef __AVR_ENHANCED__
	adiw	r30, 1
	brcs	.L__do_copy_data_carry
#endif
.L__do_copy_data_start:
	cpi	r26, lo8(__data_end)
	cpc	r27, r17
	brne	.L__do_copy_data_loop
#ifdef __AVR_HAVE_RAMPD__
	out	AVR_RAMPZ_ADDR, __zero_reg__
#endif /* __AVR_HAVE_RAMPD__*/

#endif /* BIG_CODE */

note the last OUT in that - so it cannot be entering main() with RAMPZ set.

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

Did the version of avrlibc supplied with winavr-20090313 have the problem? We switched to winavr20100110 after giving up on the xmega256.

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

The joy of CVS is that on that linked web site you can go back and look at any revision from any check in. The following two checkins look relevant:

Revision 1899 - (view) (download) (annotate) - [select for diffs] 
Modified Mon Mar 2 21:08:29 2009 UTC (2 years, 1 month ago) by arcanum 
File length: 7366 byte(s) 
Diff to previous 1764 
2009-03-02  Eric B. Weddington  

	* crt1/gcrt1.S (__do_copy_data): Make clearing of RAMPZ at end
	conditional on __AVR_HAVE_RAMPD__ (currently avrxmega3, avrxmega5,
	and avrxmega7 architectures). These architectures can access > 64K RAM,
	hence RAMPZ is required to be cleared.

--------------------------------------------------------------------------------
Revision 1764 - (view) (download) (annotate) - [select for diffs] 
Modified Tue Oct 7 20:34:58 2008 UTC (2 years, 6 months ago) by arcanum 
File length: 7311 byte(s) 
Diff to previous 1657 
2008-10-07  Eric B. Weddington  

	* crt1/gcrt1.S: Clear the RAMPZ register after __do_copy_data for
	devices > 64K flash.

FYI "arcanum" = Eric Weddington

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

I checked into the startup files. See disassembly of crtx128a1.o below. It looks like the AVR Studio 5 does not include the BIG_CODE extension though it claims to be 1.7.1 (maybe just not defined durig the build). I filed a bug report at ATMEL.

 1ec:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
 1f0:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>

Disassembly of section .init2:

00000000 <.init2>:
   0:   11 24           eor     r1, r1
   2:   1f be           out     0x3f, r1        ; 63
   4:   c0 e0           ldi     r28, 0x00       ; 0
   6:   d0 e0           ldi     r29, 0x00       ; 0
   8:   de bf           out     0x3e, r29       ; 62
   a:   cd bf           out     0x3d, r28       ; 61
   c:   00 e0           ldi     r16, 0x00       ; 0
   e:   0c bf           out     0x3c, r16       ; 60
  10:   18 be           out     0x38, r1        ; 56
  12:   19 be           out     0x39, r1        ; 57
  14:   1a be           out     0x3a, r1        ; 58
  16:   1b be           out     0x3b, r1        ; 59

Disassembly of section .init9:

00000000 <.init9>:
   0:   0e 94 00 00     call    0       ; 0x0 <.init9>
   4:   0c 94 00 00     jmp     0       ; 0x0 <.init9>
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It looks like the AVR Studio 5 does not include the BIG_CODE extension though it claims to be 1.7.1

What are you talking about?:

  16:   1b be           out     0x3b, r1        ; 59 

What do you think the above line does?

EDIT: what's more I just (after waiting 10 minutes) managed to build this for 128A1:

#include 
#include 

int n = 12345;

int main(void)
{

    while(1)
    {
    }
}

and with a variable in .data it created:

 20a:	1b be       	out	0x3b, r1	; 59

0000020c <__do_copy_data>:
 20c:	10 e2       	ldi	r17, 0x20	; 32
 20e:	a0 e0       	ldi	r26, 0x00	; 0
 210:	b0 e2       	ldi	r27, 0x20	; 32
 212:	ea e3       	ldi	r30, 0x3A	; 58
 214:	f2 e0       	ldi	r31, 0x02	; 2
 216:	00 e0       	ldi	r16, 0x00	; 0
 218:	0b bf       	out	0x3b, r16	; 59
 21a:	02 c0       	rjmp	.+4      	; 0x220 <__do_copy_data+0x14>
 21c:	07 90       	elpm	r0, Z+
 21e:	0d 92       	st	X+, r0
 220:	a2 30       	cpi	r26, 0x02	; 2
 222:	b1 07       	cpc	r27, r17
 224:	d9 f7       	brne	.-10     	; 0x21c <__do_copy_data+0x10>
 226:	1b be       	out	0x3b, r1	; 59
 228:	0e 94 1a 01 	call	0x234	; 0x234 

Note the final OUT in that. There is no fault here and this is the AS5 toolchain. (libc 1.7.1)

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

First, many thanks to the detailed and fast replies. Then, yesterday I messed up the details in my posting: of course the init code clears RAMPZ.

What I did not point out: I miss the modified part about copying data. The gcrt1.S source contains an override, so I expected the crt128A1.o to contain that .init4 section as well:

...
#if BIG_CODE
	/* Only for >64K devices with RAMPZ, replaces the default code
	   provided by libgcc.S which is only linked in if necessary.  */

	.section .init4,"ax",@progbits
	.global __do_copy_data

__do_copy_data:
...

Now let's compare your demo (i guess footprint quite small) with the same part of my application (code size above 64K). There is a difference in the initalization of r16, just before writing to RAMPZ.

from the demo application:
...

    14fc:	18 be       	out	0x38, r1	; 56
    14fe:	19 be       	out	0x39, r1	; 57
    1500:	1a be       	out	0x3a, r1	; 58
    1502:	1b be       	out	0x3b, r1	; 59

00001504 <__do_copy_data>:
    1504:	14 e2       	ldi	r17, 0x24	; 36
    1506:	a0 e0       	ldi	r26, 0x00	; 0
    1508:	b0 e2       	ldi	r27, 0x20	; 32
    150a:	ea eb       	ldi	r30, 0xBA	; 186
    150c:	f7 e1       	ldi	r31, 0x17	; 23
    150e:	01 e0       	ldi	r16, 0x01	; 1
    1510:	0b bf       	out	0x3b, r16	; 59
    1512:	02 c0       	rjmp	.+4      	; 0x1518 <__do_copy_data+0x14>
    1514:	07 90       	elpm	r0, Z+
    1516:	0d 92       	st	X+, r0
    1518:	a8 31       	cpi	r26, 0x18	; 24
    151a:	b1 07       	cpc	r27, r17
    151c:	d9 f7       	brne	.-10     	; 0x1514 <__do_copy_data+0x10>

0000151e <__do_clear_bss>:
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Neither of the two startup files provided with AS5 contains the .init4 section.

Should there be more variants depending on the final size, which will be selected by the linker? Or should the gcrt1.S always be compiled with the BIG_CODE define enabled?

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

Take a look at the line above:

#if BIG_CODE

that is:

#if defined(__GNUC__) && ((__GNUC__ <= 3) || (__GNUC__ == 4 && __GNUC_MINOR__ <= 3))
#if BIG_CODE

then:

D:\Program Files\Atmel\AVR Studio 5.0\extensions\Application\AVR Toolchain\bin>a
vr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.2.0_253) 4.5.1

So sounds like there was a change in the location of _do_copy_data and _do_clear_bss at 4.4.x

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

Are you doing anything "manually" to the stack pointer. For some of the larger chips, 3 bytes are pushed on the stack for a call. I have a task scheduler that had similar behavior in switching tasks.

also, GCC uses 2 byte pointers for pointers to code. If you use this feature to point to a high memory function, you'll get a similar failure.

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

RickSharpe wrote:
GCC uses 2 byte pointers for pointers to code. If you use this feature to point to a high memory function, you'll get a similar failure.
I thought GCC used a trampoline structure to catch calls that cross a 64k word boundary to solve this problem.

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

May be this helps. I've found a similar problem and the cause was not setting NVM.CMD to no operation after using some functions in the sp_driver (self programming) that use the NVM controller. An ELPM instruction (derived from a C switch instruction) failed to read the proper contents in flash and resulted in an invalid branch.

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

fernan.fernan wrote:
An ELPM instruction (derived from a C switch instruction)
avr-gcc does not use ELPM in switch instructions.

avrfreaks does not support Opera. Profile inactive.

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

LOL I dont know what the h3@^& you guys are talking about in general above : ) but once my XMEGA 256A3B AVR20100110 project started resetting on its own and acting chaotically I moved to AVR Studio 5 and it was instantly stable.

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

To SprinterSB: I use the IAR compiler. It looked up the address to jump to from a table in flash. I just wanted to point out a possible cause, just in case someone arrives to this thread as I did.

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

Hi
I found the same problem on an xmega128A1, when my program excited 64K it stopped working. This small test program shows the problem:

#include "avr_compiler.h"

char PROGMEM test_string0[1024][31];
char PROGMEM test_string1[1024][31];

//Remove this line and it is working
char PROGMEM test_string2[1024][10];

//Or remove this line and it is working
int test1 = 1234;

void delay();
#include 

int main(void)
{
  //Or ADD this line and it is working
  asm("ldi  R16, 0 \n"
      "out  0x3B, R16"
      );
 	
   PORTH.DIRSET=PIN0_bm;
   PORTH.OUTSET=PIN0_bm;
   while(1)
   {
     PORTH.OUTTGL=PIN0_bm;	
     delay();
   }
}

void delay()
{
   unsigned int n,m;
   for(m=0;m<25;m++)
     for(n=0; n<1000; n++)
	;		
}	

I am using
Atmel AVR Studio 5 (Version: 5.1.208)
AVRGCC Version: 3.3.1.27