TWI vector riddle

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

I have blamed God, the Universe, GCC and Atmel (in this order; I wrote the code alone, otherwise I would have blamed anyone else involved as well) for this, but now I think the error is due to me, but I can't figure out what is wrong with my code...

In short: I'm trying to pilot the I2C bus as master with a AT90USB647. The code is attached, and I compile it with

avr-gcc -std=c99 -W -Wall -pedantic -Wstrict-prototypes -Wundef -Werror -funsigned-char -funsigned-bitfields -ffunction-sections -fpack-struct -fshort-enums  -ffreestanding -Os -g -gdwarf-2 -DF_CPU=8000000UL -mmcu=at90usb647  -Wl,--relax -Wl,--gc-sections main.c -Wl,-Map,i2c.map -o i2c.elf

My problem is: if I declare the ISR, as anyone would do, with

ISR(TWI_vect)

then the interrupt is NOT being called. If I instead call the TWI interrupt

Quote:
ISR(INT6_vect)
then everything works as expected and I see the desired string ("Hi"; a "Hello World!" would be way too long...) on the I2C slave display.

I have checked the list file, and there is no twist in the interrupt vectors. The TWI int is number 37 as in the datasheet, and INT6 is vector number 8 in the datasheet, so I can exclude an error in GCC's header files. I have contacted Atmel for it and they confirmed it: TWI is vector 37 on a AT90USB647.

I'm using avr-gcc v4.3.0 on Debian/Linux. There is no other interrupt initialised and no interrupt vector other than the TWI vector and the Reset vector are configured.

Has anyone an idea what I'm doing wrong? I got a similar code working as a slave on a ATmega644, so I really don't know why this version does not work at all. Any clue?

Thomas

Attachment(s): 

pycrc -- a free CRC calculator and C source code generator

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

I tried ISR(TWI_vect) with the simulator and it jumps to 0x4E instead of 0x48. :o

When I compiled it for Atmega128 the simulator jumped to the right place.

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

The include file that eventually gets pulled as an effect of #include is iousbxx6_7.h if I got it right. I am currently looking in a rather old WinAVR installation (20070525) and on line 1267-8 in that file I find

/* 2-wire Serial Interface */
#define TWI_vect			_VECTOR(36)

What do you have in your iousbxx6_7.h?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

WinAVR-20080512 has...

/* 2-wire Serial Interface */
#define TWI_vect			_VECTOR(36)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

my iousbxx6_7.h has the correct content:

/* 2-wire Serial Interface */
#define TWI_vect                        _VECTOR(36)

and in the .lss file the vector is at address 0x90 (0x48 expressed in words).

  90:   5d c0           rjmp    .+186       ; 0x14c <__vector_36>

And INT6_vect is at address 0x1C (0x0E).
I think GCC's header file is correct.

As a side note: after atomicdog's post I have tried to run the code in AVRStudio's simulator on Windows, and really the simulator jumps to the wrong interrupt vector. But I think this is a bug in the simulator and not related to my problem. :-(

Thomas

pycrc -- a free CRC calculator and C source code generator

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

Found the culprit: the same .elf file downloaded with AVRStudio's downloader works. A Read-back of the Flash content shows the rason.

This is the flash content (Intel hex format) when I program with avrdude under Linux:

:100000007F454C4601010100000000000000000097
:100010000200530001000000000000003400000056
:10002000241C00008500000034002000020028008D
:1000300011000E000100000074000000000000002C
:1000400000000000A8020000A80200000500000057
:1000500001000000010000001C03000000018000FE
:100060000001800000000000060000000600000003
:10007000010000004BC0000064C0000062C000002E
...

This is the Flash content when I program with AVRStudio:

:100000004BC0000064C0000062C0000060C000007F
:100010005EC000005CC000005AC0000058C0000074
...

When I program with avrdude, I get an additional 0x74 (116) bytes offset. This explains that the interrupt vector is mis-aligned.

I program the elf file like this:

avrdude -cdragon_jtag -pusb647 -Pusb -F -e -Uflash:w:i2c.elf

Is there something wrong with how I call avrdude?

(Please note that I need to use the -F switch to suppress a signature mismatch between the AT90USB647 device and the avrdude.conf file; my bug report on avrdude-dev didn't find much resonance so far.)

Thomas

Update:
If I use .hex file format instead of .elf, then it seems to work correctly.

avr-objcopy -O ihex i2c.elf i2c.hex
avrdude -cdragon_jtag -pusb647 -Pusb -F -e -Uflash:w:i2c.hex

pycrc -- a free CRC calculator and C source code generator

Last Edited: Sun. Jul 20, 2008 - 05:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

are you saying it's the very identical .hex file in both the Windows/Studio and Linux/avrdude environment? Or are you building it separately in each place? If the latter then the 100 byte offset is probably a result of a build error in the Linux environment and nothing to do with your use of avrdude.

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

Hi clawson,

if I program the same .hex file (generated on Linux), with either AVRStudio or avrdude on Linux, then I have no problems.

If I program the same .elf file (generated on Linux), as I did initially, then I run into problems:

    on Windows with AVRStudio the program runs fine. on Linux with avrdude apparently I get an offset of 116 bytes when I read the image back.
I will ask about it on the avrdude mailing list.

Thomas

pycrc -- a free CRC calculator and C source code generator

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

"Doctor, doctor, it HURTS when I program the AVR with the .elf file!"

"Then don't program with the .elf file. That will be $20."

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

Actually, my intention was that one:

"Doctor, doctor, it HURTS when I program the AVR with the .elf file!"
"Then let's fix/document it. It might hurt someone else as well."

Thomas

pycrc -- a free CRC calculator and C source code generator