View topic - Incorrect ISR Vector Map?

Search

Incorrect ISR Vector Map?

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR GCC forum

Author

Message

wesanyer

Posted: Nov 23, 2011 - 02:10 AM

Joined: Nov 18, 2011
Posts: 11

Hey guys, new to the forums and to atmel uProcessors in general. I'm working on an Atmega32u4 as implemented in the Teensy2.0 . I'd like to set up an ISR which fires when an ADC (in free-running mode) completes and which updates the value of OCR1A. I am having difficulties accomplishing this though (I'll attach my code). Looking at the datasheet for the Atmega32u4, I see that the vector number for ADC Conversion Complete is 30 (page 62). When I look at my /usr/avr/include/avr/iom32u4.h (which is the file which is sourced in /usr/avr/include/io.h for the Atmega32u4) I see the following line:

#define ADC_vect _VECTOR(29) /* ADC Conversion Complete */

It seems to me that all the vectors on this table are off by one. could that be? I tried manually calling _VECTOR(30) in place of ADC_vect but still don't have success.

It could very well be my implementation that is incorrect, and feel free to pipe up if it is, but really by question here is whether or not this vector table in my avr-gcc could be wrong.

Thanks!

sternst

Posted: Nov 23, 2011 - 02:26 AM

Joined: Jul 23, 2001
Posts: 2438
Location: Osnabrueck, Germany

Quote:

It seems to me that all the vectors on this table are off by one.

It is merely a different counting. Numbers are totally irrelevant anyway. Addresses are relevant. And when you look into the lss file you will see that the vector is at the correct address.

_________________
Stefan Ernst

wesanyer

Posted: Nov 23, 2011 - 02:34 AM

Joined: Nov 18, 2011
Posts: 11

sternst wrote:

It is merely a different counting.

This is what I thought the case may be, but I did not know enough about the underlying mechanics at play to research it myself. Thank you for clarifying that for me. Did you personally check this 'lss' file or are you just assuming that the underlying address is indeed correct?

Thanks

Edit: as a follow up, any idea what my problem may be? Is this the appropriate forum to ask for this sort of help, or is there a better suited one?

sternst

Posted: Nov 23, 2011 - 02:41 AM

Joined: Jul 23, 2001
Posts: 2438
Location: Osnabrueck, Germany

wesanyer wrote:

Did you personally check this 'lss' file or are you just assuming that the underlying address is indeed correct?

No, just assuming.

wesanyer wrote:

Edit: as a follow up, any idea what my problem may be?

What are the symptoms? "having difficulties accomplishing this" does not tell us anything.

_________________
Stefan Ernst

wesanyer

Posted: Nov 23, 2011 - 02:48 AM

Joined: Nov 18, 2011
Posts: 11

I'm able to use the ADC correctly in a 'polling' mode (I can upload the sligthly different code I'm using for that if you'd like to see) but when I switch to trying to use the interupt routine I am no longer able to capture the changes.

My use-case is that I am using the setting of a potentiometer (set up between Gnd and Vcc) to set the duty cycle of a low-frequency PWM. You'll notice I do some funny stuff with two timers, and that's because I wanted to get a really slow frequency on my PWM. To accomplish this, I set up the overflow of the 8-bit timer with a pre-scale to toggle T1, which timer 1 is now using as it's clock. I'm pretty proud of this setup actually, that's why I'm sharing it without being asked Razz

sternst

Posted: Nov 23, 2011 - 02:53 AM

Joined: Jul 23, 2001
Posts: 2438
Location: Osnabrueck, Germany

wesanyer wrote:

but when I switch to trying to use the interupt routine I am no longer able to capture the changes.

What build environment do you use? Have you compiled/linked the code for the correct mcu?

_________________
Stefan Ernst

wesanyer

Posted: Nov 23, 2011 - 02:56 AM

Joined: Nov 18, 2011
Posts: 11

I am using avr-gcc compiled on a gentoo box using the cross-dev script. I have been successfully compiling code for the chip for a few days now, so I doubt if that is the problem. I am using a Makefile provided by my board 'manufacturer' (pjrc.com) and have set the appropriate MCU field to atmega32u4.

update:
avr-gcc --version = 4.4.6

sternst

Posted: Nov 23, 2011 - 02:58 AM

Joined: Jul 23, 2001
Posts: 2438
Location: Osnabrueck, Germany

Quote:

I am using a Makefile

Post it.

_________________
Stefan Ernst

wesanyer

Posted: Nov 23, 2011 - 03:05 AM

Joined: Nov 18, 2011
Posts: 11

http://paste.pocoo.org/show/511720/ <-- it's a doozy of a Makefile, I warn you. I started using the Makefile template provided on here, but ran into some (non- Makefile related) issues and started using the pjrc-provided Makefile to eliminate that as an issue: I didn't have the patience to parse through it (and learn make-speak) to find any differences/similarities from what is provided on this website.

sternst

Posted: Nov 23, 2011 - 03:19 AM

Joined: Jul 23, 2001
Posts: 2438
Location: Osnabrueck, Germany

I don't see a problem in the Makefile.

Quote:

I am using avr-gcc compiled on a gentoo box using the cross-dev script.

I am not familiar with that script. Does it apply any avr specific patches or does it only compile the plain unpatched gcc sources for the avr target?

_________________
Stefan Ernst

wesanyer

Posted: Nov 23, 2011 - 03:38 AM

Joined: Nov 18, 2011
Posts: 11

http://paste.pocoo.org/show/511732/ here is the script in whole, and more info can be seen here: http://en.gentoo-wiki.com/wiki/Crossdev . Not sure if it applies any patches, I'd be willing to say that probably not. What patches should I be concerned about? an the nongnu.org site I saw something about a binutils patch, but again I've been building code for this board just great till now.

mnehpets

Posted: Nov 23, 2011 - 09:35 AM

Joined: Nov 09, 2011
Posts: 399

Hmmmm...

Code:

$ grep ADC_vect avr/include/avr/iom32u4.h

#define ADC_vect            _VECTOR(29)  /* ADC Conversion Complete */

As you say, the ADC completion vector is numbered 29 using avr-libc's numbering.

Code:

$ avr-objdump -r --start-address=0x70 --stop-address=0x78 -j .vectors avr/lib/avr5/crtm32u4.o 

avr/lib/avr5/crtm32u4.o:     file format elf32-avr

RELOCATION RECORDS FOR [.vectors]:

OFFSET   TYPE              VALUE 

00000070 R_AVR_CALL        __vector_28

00000074 R_AVR_CALL        __vector_29

00000078 R_AVR_CALL        __vector_30

The linker places vector 29 at byte address 0x74. Divide 0x74 by 2 to get the word address of 0x3a. This matches the address of the ADC vector in table 9-1 of the ATmega32u4 datasheet.

So, the avr toolchain should put the vector at the right address.

If you want to verify that your interrupt code is correctly being targetted in your own built code, you can do "make elf", followed by "avr-objdump -d timer.elf" to get the disassembled output.

- S

mnehpets

Posted: Nov 23, 2011 - 09:51 AM

Joined: Nov 09, 2011
Posts: 399

As a ps, your ADC clock seems to be way too high. You should check: the external xtal frequency, the system prescaler, and finally the ADC prescaler. The resulting ADC clock should be between 50 and 200kHz.

- S

clawson

Posted: Nov 23, 2011 - 09:55 AM

Joined: Jul 18, 2005
Posts: 62299
Location: (using avr-gcc in) Finchingfield, Essex, England

Does Gentoo use .deb or .rpm? If .deb then you could use prebuilt avr-gcc packages from www.wrightflyer.co.uk/avr-gcc/ which are built using Bingo's script (see sticky at top of this forum).

_________________

sternst

Posted: Nov 23, 2011 - 02:05 PM

Joined: Jul 23, 2001
Posts: 2438
Location: Osnabrueck, Germany

clawson wrote:

Does Gentoo use .deb or .rpm?

Neither. Gentoo is a different kind of beast. It uses no binary packages. A Gentoo package is mainly a script, which downloads the source, apply patches, build and copy the binaries, and do the Gentoo administrative stuff.

But actually it doesn't matter. You can unpack a .deb package with standard tools. There is no need to have the complete Debian package infrastructure installed.

wesanyer,
if you like you can post the lss file and we will see whether the problem comes from faulty code generated by an unpatched avr-gcc. But it would be a good idea to use one of the prebuild avr-gcc mentioned by Cliff anyway.

_________________
Stefan Ernst

wesanyer

Posted: Nov 24, 2011 - 01:41 AM

Joined: Nov 18, 2011
Posts: 11

http://paste.pocoo.org/show/512175/ <- here is the dissembled code. http://paste.pocoo.org/show/512176/ <- here is the C code which is shown dissembled. I re-post it because I think I may have made a few tweaks since I posted originally.

mnehpets: I am aware of the clock frequency limitations of the ADC. I have attempted using one of the ADC's built-in pre-scalers (I used the largest one if I recall) and that didn't seem to help. I then went back to no pre-scale and instead set the 'high speed' bit but still the same problems.

I appreciate all of your guys' help! I would rather not rebuild my toolchain, though I will go that route if I have to. If there is a way to verify my toolchain as-is though, that would be preferable.

Thanks.

sternst

Posted: Nov 24, 2011 - 08:21 AM

Joined: Jul 23, 2001
Posts: 2438
Location: Osnabrueck, Germany

Quote:

here is the dissembled code. ... here is the C code which is shown dissembled.

You have definitely a major problem with your toolchain. Theres is not a bit of the ISR in the disassembly. Neither a jump in the vector table, nor any code for the ISR itself.

_________________
Stefan Ernst

wesanyer

Posted: Nov 24, 2011 - 05:15 PM

Joined: Nov 18, 2011
Posts: 11

I should note that I have succusfully compiled and run some code which uses an interrupt vector on this chip. Here is the code and the dissembled code: http://paste.pocoo.org/show/512436/, and http://paste.pocoo.org/show/512437/. Would anyone care to enumerate for me the patches that are applied in the script stickied in this forum? I assume they add greater support for atmel chips to a version of gcc that doesn't otherwise support them, as I have tried a 4.3.5 avr-gcc but it didn't have support for my chip.

clawson

Posted: Nov 24, 2011 - 05:19 PM

Joined: Jul 18, 2005
Posts: 62299
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

I assume they add greater support for atmel chips to a version of gcc that doesn't otherwise support them, as I have tried a 4.3.5 avr-gcc but it didn't have support for my chip.

Some of the patches are for device support. Some are for fixes for serious code generation errors. Often the patch names are fairly self explanatory. For example here are the patches used in WinAVR (4.3.3):

Code:

 Directory of E:\WinAVR-20100110\source\avr\gcc\4.3.3

19/01/2010  18:08             7,276 60-gcc-4.3.3-osmain.patch

19/01/2010  18:08             7,348 47-gcc-4.3.3-bug-18145-v4.patch

19/01/2010  18:08            11,119 41-gcc-4.3.3-bug-11259_v3.patch

19/01/2010  18:08            16,365 61-gcc-4.3.3-builtins_v6.patch

19/01/2010  18:08            33,036 51-gcc-4.3.3-xmega-v13.patch

19/01/2010  18:08             2,914 45-gcc-4.3.3-bug-33009.patch

19/01/2010  18:08             1,348 44-gcc-4.3.3-libgcc16.patch

19/01/2010  18:08            10,560 50-gcc-4.3.3-mega256-v2.patch

19/01/2010  18:08             6,084 62-gcc-4.3.3-ada-mlib.patch

19/01/2010  18:08             3,458 63-gcc-4.3.3-ada-freestanding.patch

19/01/2010  18:08               629 30-gcc-4.3.3-param-inline-call-cost.patch

19/01/2010  18:08             1,606 42-gcc-4.3.3-bug-spill-v4.patch

19/01/2010  18:08             3,026 66-gcc-4.3.3-ada-optim_static_addr.patch

19/01/2010  18:08             1,312 65-gcc-4.3.3-ada-gnat1_print_path.patch

19/01/2010  18:08               392 20-gcc-4.3.3-libiberty-Makefile.in.patch

19/01/2010  18:08               445 46-gcc-4.3.3-andsi3-wrong-attribute.patch

19/01/2010  18:08             1,656 40-gcc-4.3.3-bug-10768-by-adacore.patch

19/01/2010  18:08             2,209 43-gcc-4.3.3-bug-35013.patch

19/01/2010  18:08               924 21-gcc-4.3.3-disable-libssp.patch

19/01/2010  18:08            24,718 52-gcc-4.3.3-new-devices.patch

19/01/2010  18:08               339 23-gcc-4.3.3-ada-Makefile.patch

19/01/2010  18:08             2,645 64-gcc-4.3.3-ada-timebase.patch

Code:

=================================================================================

_________________

wesanyer

Posted: Nov 25, 2011 - 02:24 AM

Joined: Nov 18, 2011
Posts: 11

clawson - I've just spent the better part of the day trying to build an avr toolchain using the aforementioned script but have yet to succeed. I've run into issues with the binutils patching (which I was able to overcome), mpfr patching (which, again, I was able to overcome) and now I am having a problem with the gcc build which I cannot get through. As have already built and run succesful code which incorporates an interupt, I'm loathe to believe that there is anything wrong with my toolchain as it stands.

Are there any other steps we can take to validate whether or not my toolchain is alright as it is, and maybe the problem lies elsewhere? Could maybe one of you fine folks compile my timer.c code on your working toolchains such that we can compare our dissembled code?

Thank you.

mnehpets

Posted: Nov 25, 2011 - 06:26 AM

Joined: Nov 09, 2011
Posts: 399

Attached in a zip file are timer.elf, timer.o and timer.hex. This is a compile of timer.c from http://paste.pocoo.org/show/512176/. The build output looked something like:

Code:

$ avr-gcc -c -mmcu=atmega32u4         -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./timer.lst  -std=gnu99  timer.c -o timer.o

timer.c: In function '__vector_29':

timer.c:77: warning: unused variable 'high'

timer.c:77: warning: unused variable 'low'

$ avr-gcc -mmcu=atmega32u4         -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=timer.o  -std=gnu99 -MMD -MP -MF timer.elf.depend timer.o --output timer.elf -Wl,-Map=timer.map,--cref -Wl,--relax -Wl,--gc-sections     -lm

$ avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature timer.elf timer.hex

This was built using CrossPack 20100115, which is a port of the most recent winavr to mac.

- S

sternst

Posted: Nov 25, 2011 - 11:02 AM

Joined: Jul 23, 2001
Posts: 2438
Location: Osnabrueck, Germany

Quote:

I've just spent the better part of the day trying to build an avr toolchain using the aforementioned script but have yet to succeed.

I do not understand why you don't simply take a prebuild avr-gcc from here http://www.wrightflyer.co.uk/avr-gcc/.
ATmega32u4 is supported by the 4.3.3 version I have in use, so I bet it is also supported by the versions you can download there.

_________________
Stefan Ernst

wesanyer

Posted: Nov 26, 2011 - 12:39 AM

Joined: Nov 18, 2011
Posts: 11

mnehpets: thanks for posting those files, checking your timer.elf versus mine using avr-objdump I see some definite differences. I suppose that this does indeed point to my toolchain then.

Sternst: I am not on a debian-based Linux box, so I can't really make use of the .deb files you linked too. I suppose I could unpack them and extract the relevant binaries, but I'm not sure if it's quite so simple as that.

Thanks.

sternst

Posted: Nov 26, 2011 - 02:11 AM

Joined: Jul 23, 2001
Posts: 2438
Location: Osnabrueck, Germany

wesanyer wrote:

I suppose I could unpack them and extract the relevant binaries, but I'm not sure if it's quite so simple as that.

It IS as simple as that. Download the .deb and do this:

Code:

ar p avr-gcc-*.deb data.tar.gz | tar xzC /

Then you have a working toolchain under /usr/local/avr/

_________________
Stefan Ernst

wesanyer

Posted: Nov 26, 2011 - 02:51 AM

Joined: Nov 18, 2011
Posts: 11

sternst: sweet, worked a charm. let me try this code on my chip now.

update: you guys were right, it was a problem with my toolchain. Using the pre-compiled toolchain results in a perfectly working interrupt. Thanks for the help!

Jump to:

All times are GMT + 1 Hour

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR GCC forum

AVRFreaks.net

Search