attiny2313a / attiny2313 / AVR studio 4.18 / WinAVR 2010 problem

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

We're using the attiny2313a, and have been for some time. All works. AVR studio project file still showed attiny2313, aka 2323(v) which was clearly not a problem, because the device continued to work.

 

If I tell AVR studio / GCC that I'm using the attiny2313a, the code grows by 4 bytes, as expected: space is reserved in the vectors for two new (unused) interrupt vectors. This is not a problem: the code size grows from 2040 to 2044 (out of 2048).  (And the last 4 bytes of a program are always unused junk inserted by GCC anyway.)

 

But it doesn't work. The device is unresponsive to normal inputs.

 

Does anyone know what might be going wrong? The listing looks identical, just shifted down 4 bytes, so I'm thinking I don't understand something.

 

 

[I hate the graphic design of avrfreaks]

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

Atmel have produce migration notes for the A devices. Have you looked at the one for 2313 -> 2313A?

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

AVR533: Migrating from ATtiny2313 to ATtiny2313A, but nothing that I can see. The painfull thing is that, due to the extra 4 bytes at teh start of the program, the whole hexdump is different, which makes it more work to do a binary comparision

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

Couldn't you build the previous code with a dummy 4 bytes in that position to restore the offset?

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

Indeed, puzzling for a vanilla app rebuilt for the new target.

 

Could it be that with the old toolchains there was a problem with the "new" '2313A since resolved?

 

I'd look at the maps and linker scripts, to see if something was hard-placed at an address that is now different.

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.