Attiny861 flash size

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

Hi,

I'm working on a project with the ATtiny861, using version 4.17 of AVR studio (build 666), with AVRGCC. When my program reaches over 4K in the flash size, I get a "relocation truncated to fit: R_AVR_13_PCREL against "˜no symbol'" message.

From what I can tell, AVR studio thinks the Atiny861 is a 4K part, it is an 8K part. If you go to Project -> Configuration Options and the click Memory Settings, you'll see the flash size is 0x1000 (4K). I assume AVR studio is getting this number from some file, but I have not been able to find the file. Maybe this is an AVRGCC issue. Any ideas about how to change the flash size to 0x2000?

Thanks,
Matt M.

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

The Studio Project configuration reports the WORD size of flash memory. After all this is what the flash is used for.

It happens that avr-gcc chooses to think in bytes for its own reasons. It also suits Atmel Marketing people to refer to a device with 4k words as 8k. If you want to see some real lies you should look at speakers for your PC.

In terms of your relocation, you will just have to look at the generated code. It may rely on code wrapping around to zero. Or you may be trying something illegal.

David.

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

Which version of AVR-GCC are you using? Is it an official WinAVR derivative?

According to what I can tell from this mailing list conversation, it looks as though some older (but relatively recent) versions of WinAVR included a bug in binutils where the linker would fail to apply wraparound jumps to devices that were members of the avr25 architecture. (This would include the ATtiny861.)

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

David,
I’ve used Attiny2313 parts before with what I assume is 2K bytes of flash. Compiling the code doesn’t stop at 1K. So, I’m not sure why the Attiny861 would be different.

Morrison,
I was using 20081205 of WinAVR, but then tried 20090313. Both versions are official derivatives, downloaded from source forge. The 20090313 version goes past the 4K byte limit. (interesting note: Project -> Configuration Options and the click Memory Settings, still reports the flash size as 0x1000)
Thanks for your help, I’m able to go on with the project now.
Matt

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

An ATtiny2313 has 1K words of flash. You can fill it with ASM instructions and get a location counter that goes from 0x000 to 0x3FF. All the operands are in words.

You can obviously call it 2K bytes or if you prefer 4K nybbles or even 16K bits.

You have a similar situation with a PIC16Fxxx or PIC18Fxxx. The former has 14 bits of program word, so you do not even get 2 whole bytes per program word.

Personally I look to how much useful program instructions I can get into a Tiny2313. If part of the program space is used for data, I can get 2 bytes of data storage per program word.

David.

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

matt6ft9 wrote:
David,
I’ve used Attiny2313 parts before with what I assume is 2K bytes of flash. Compiling the code doesn’t stop at 1K. So, I’m not sure why the Attiny861 would be different.

There is no difference - an ATtiny2313 does contain 2KB of Flash, and an ATtiny861 does contain 8KB of Flash. The difference in this case actually comes from a bug in the linker when dealing with different variants of the AVR core.

Different AVRs have slight variations in the instruction set, mainly dealing with the presence or absence of a hardware multiplier, or adding extended addressing modes for accessing Flash or data memory.

Another major difference is that devices with 8KB or less of Flash supposedly do not implement the absolute jump and call instructions, because the shorter and faster relative jump and call instructions are adequate to jump to and from any location in 8KB or less of Flash.

The relative jump and call instructions can normally only jump forwards and backwards by a maximum of 4KB relative to the current instruction. If you have a part with 4KB of Flash or less, then it's a straightforward exercise to jump from any location in Flash to any other location.

However, parts with up to 8KB of Flash can still use relative jumps to reach any location in Flash, but the method is slightly less obvious. They achieve the feat by taking advantage of the fact that when an AVR relatively jumps to a location beyond the end of Flash, it actually wraps around to a location at the beginning of Flash. A similar wraparound happens when you jump backwards to a location before the beginning of Flash.

The AVR-GCC linker knows the core architectural variant of the AVR device you're targeting, and by default, it will only take advantage of the wraparound nature of the relative jump and call instructions if its architectural definition for the part says it's supported. Otherwise, if it attempts to link a relative jump or call instruction to a target that appears to be outside the linear reach of the relative instructions, it will abort.

The bug in this case was that the linker didn't know that the architecture used by the ATtiny861 supported wrap-around relative calls and jumps.

Quote:
Morrison,
I was using 20081205 of WinAVR, but then tried 20090313. Both versions are official derivatives, downloaded from source forge. The 20090313 version goes past the 4K byte limit.

The 2008 version of WinAVR was almost certainly affected by the bug noted above, considering the fact that Eric had said in January 2009 that the fix wasn't going to be released as part of WinAVR until some time later that year - clearly, the release from March of this year must have been it. I'm glad it resolves your problem.