ATtiny10 problems

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

I am using the AVR toolchain version 3.0.0.240, and AVR Studio V4.18 build 716 to compile a C program for the ATtiny10 family.

I am currently compiling for the ATtiny10 (instead of the desired ATtiny4) as the generated code is much bigger than expected and fits onto the ATtiny10 when optimised.

There are some strange issues which I am seeing that don't seem to make any sense.

I was trying to simulate the code (using the AVR Simulator 2 and ATtiny10 option) and noticed that the location of the variables was outside of the memory space. The compiler says that only 11 bytes of the Data section are used, but it is placing the variables in a strange place.

The variables appear to be placed starting at 0x0060, which is not the SRAM location, they should be placed starting at 0x0040 - 0x005F. This is seen my mousing over the variable when debugging.

I then had a look at the .map file that is being generated, and it has the following close to the start,

Memory Configuration

Name             Origin             Length             Attributes
text             0x00000000         0x00002000         xr
data             0x00800060         0x0000ffa0         rw !x
eeprom           0x00810000         0x00010000         rw !x
fuse             0x00820000         0x00000400         rw !x
lock             0x00830000         0x00000400         rw !x
signature        0x00840000         0x00000400         rw !x
*default*        0x00000000         0xffffffff

which bears no resemblance to the memory mapping of the ATtiny10 family. If you only look at the lower two bytes of the data address it is equal to 0x0060.

I then looked at the .lss file which also indicates that the variables are accessed in memory which does not exist, e.g. mode is stored at 0x0064.

                mode ^= 1;          // Invert the mode (only on or off)
 382:	90 91 64 00 	lds	r25, 0x0064
 386:	81 e0       	ldi	r24, 0x01	; 1
 388:	89 27       	eor	r24, r25
 38a:	80 93 64 00 	sts	0x0064, r24

I have also noticed that some optimisations are not being performed as expected (with -Os). There are some places that I use sfr |= _BV(bit), and that is not being optimised to a sbi (or cli) command. Certain places it does, others it does not, e.g. (optimised code)

    // Disable the pin change interrupt
    PCICR &= ~(_BV(PCIE0));
  60:	e2 e1       	ldi	r30, 0x12	; 18
  62:	f0 e0       	ldi	r31, 0x00	; 0
  64:	80 81       	ld	r24, Z
  66:	8e 7f       	andi	r24, 0xFE	; 254
  68:	80 83       	st	Z, r24

[snip]

            PCICR |= _BV(PCIE0);
 27a:	20 91 12 00 	lds	r18, 0x0012
 27e:	21 60       	ori	r18, 0x01	; 1
 280:	20 93 12 00 	sts	0x0012, r18

[snip]

            TIMSK0 |= _BV(OCIE0B);
 2e8:	5a 9a       	sbi	0x0b, 2	; 11

I am a bit unsure where things are going wrong - any ideas as to how to resolve this?

Thanks.

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

There's more wrong than just that:
The LDS and STS instructions are clearly the 32-bit variants, which don't exist in an ATtiny10. For an ATtiny10, it should have been using the 16-bit variant of the LDS and STS instructions.

I don't have the latest ATtiny10-supporting toolchain installed on my machine right now. I'll try and download it tomorrow, and see if I can come up with my own basic program, with a few global variables and a few I/O reads/writes. See what I come up with...

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

It really looks like the target wasn't set for that family. You gurus will need to mention the easiest way to verify that, post-build.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

lfmorrison wrote:
There's more wrong than just that:
The LDS and STS instructions are clearly the 32-bit variants, which don't exist in an ATtiny10. For an ATtiny10, it should have been using the 16-bit variant of the LDS and STS instructions.

Maybe that is a clue there - I do have the AVR32 toolchain installed as well, and there is some mention (in the install process) that it could possibly interfere with the installation. I'll have a closer look at that too.

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

engineersimplicity wrote:
Maybe that is a clue there - I do have the AVR32 toolchain installed as well

I uninstalled the AVR32 toolchain, as well as all WinAVR installations - no change.

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

lfmorrison wrote:
There's more wrong than just that:
The LDS and STS instructions are clearly the 32-bit variants, which don't exist in an ATtiny10. For an ATtiny10, it should have been using the 16-bit variant of the LDS and STS instructions.

Now that I've read up on the instruction set I actually understand what you mean. Clearly something is going wrong. I'm going to try with IAR KickStart edition in the mean time.

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

I've been wrestling with this issue, too. I contacted Atmel tech support and was told there is no C support for the ATTiny10, even though the project options seems to clearly give one. I was told to use assembly. But, even then, I got the 32 bit LDS and STS instructions. There's also a bit of confusion in the tech support group, as the first response I gte said that reason for the lack of C support was because of the lack of RAM in the ATTiny10, which I assume is because the person responding was confusing the "new" ATTiny10 with the older one (did it ever exist?) that lacked RAM. All in all, very frustrating.

Wayne

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

Wayne, I have not yet been successful with avr-gcc, but I did make some progress with the IAR compiler. I'm still not able to compile the code though.

IAR Kickstart allows up to 4kB of code with no limitations, so it can compile any code written for the ATtiny10 family without limitations.

The code it is producing makes sense and used the correct commands, so it definitely works. I am just having some trouble with it sorting out the memory (I think I have a setting wrong somewhere and the linker is moaning about RSTACK or CSTACK [depending on my settings] - and there should be plenty of space for the variables, etc.).

Try running your assembly file through the IAR compiler and see if you get the results you are looking for.

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

[apologies to the residents--heresy alert]

Although I've only done test programs, CodeVision has Tiny10-family support. I don't know what the limits on the eval version are.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

According to Atmel's betaware site, there's a newer version of the 8-bit AVR GNU toolchain, version 3.1.0.x.

http://distribute.atmel.no/tools...

One of the listed bug fixes deals with the ATtiny10 family, and the fact that the previous toolchain used LDS and STS unnecessarily with I/O registers.

It may be a good idea to try that newer toolchain. (I'm not entirely sure where you need to look to obtain the latest version of the toolchain. Oddly enough, it appears to be bundled with the latest version of AVR32 Studio, even though this is an 8-bit AVR toolchain.)

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

Information in this AVR forum thread (by hce, at the bottom): Tiny 10

"Dare to be naïve." - Buckminster Fuller

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

lfmorrison wrote:
It may be a good idea to try that newer toolchain. (I'm not entirely sure where you need to look to obtain the latest version of the toolchain. Oddly enough, it appears to be bundled with the latest version of AVR32 Studio, even though this is an 8-bit AVR toolchain.)

I unzipped the toolchain (3.1.0.206) and tried it, but the compiler is still generating faulty STS and LDS commands.

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

The 3.1.0.206 toolchain does appear to fix the optimisation issues I mentioned, the line,

PCICR &= ~(_BV(PCIE0));

now optimises to a cbi command as expected.

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

Can anyone tell me how I can install the 3.1.0.206 toolchain in the regular 8 Bit AVR Studio 4 Release?

Wayne

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

wholder wrote:
Can anyone tell me how I can install the 3.1.0.206 toolchain in the regular 8 Bit AVR Studio 4 Release?

I downloaded the zipped version of AVR32 studio from Atmel's beta site and unzipped the AVR8 part of the toolchain plugin directory to the same directory as my AVR8 toolchain install directory.

File name is as4e-ide-2.7.0.851-win32.win32.x86.zip, then extract the directory

as4e-ide-2.7.0.851-win32.win32.x86.zip\as4e-ide\plugins\com.atmel.avr.toolchains.win32.x86_3.1.0.201012011657\os\win32\x86

over your currently installed AVR toolchain. Running avr-gcc should yield

avr-gcc (AVR_8_bit_GNU_Toolchain_3.1.0_200) 4.4.3

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

I did submit a bug report to Atmel regarding this, so I will wait and see what comes from that. For the mean time I will have to consider writing the code in assembler. It is a pity, as I wanted to port this to an AVR sooner rather than later, but other than the compiler issues the code is more than 3x larger than the PIC10F200 code compiled with Hi-Tech C. I thought the hardware PWM on the ATtiny4 would actually result in even smaller code.