Poisoned Error with UART_TX_vect

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

I get a attempt to use poisoned UART_TX_vect when attempting to write interrupt routines for an ATmega8515.

ISR(UART_TX_vect)

{

}

 

However this works OK

 

ISR(INT0_vect)

{

}

 

I am using the latest version of AVR Studio 7.  It has been 8 years since I programmed for the AVR, so I am a bit rusty, but this problem has me stumped.

 

-Jim
http://www.noniandjim.com
Analog and Digital Electronics
Music Synthesizers

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

Put the error message into the 'Search' box here - or google

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isn't 'UART_TX_vect' simple the wrong name?

 

There are two ISRs for TX, one for DRE and one for TXC.

 

Look in the chip header file to find the right name.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

Nope, turns out for a mega8515 that is the right name.

 

Which might suggest that you haven't told the compiler what chip you are using.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

Last Edited: Fri. Jan 26, 2018 - 08:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"poisoned" just means "deprecated" - doesn't it?

 

It's definitely come up before - hence the search suggestion ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

USART_TX_vect should be correct.
UART_TX_vect was signed as deprecated at some time in the past.

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

The GCC Manual wrote:

#pragma GCC poison

Sometimes, there is an identifier that you want to remove completely from your program, and make sure that it never creeps back in. To enforce this, you can poison the identifier with this pragma. #pragma GCC poison is followed by a list of identifiers to poison. If any of those identifiers appears anywhere in the source after the directive, it is a hard error.

 

https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html

 

https://www.quora.com/What-does-the-pragma-GCC-poison-directive-do

 

https://github.com/vancegroup-mirrors/avr-libc/blob/master/avr-libc/include/avr/iom8515.h

/* Deprecated items */
#if !defined(__AVR_LIBC_DEPRECATED_ENABLE__)

#pragma GCC system_header

#pragma GCC poison SIG_INTERRUPT0
#pragma GCC poison SIG_INTERRUPT1
#pragma GCC poison SIG_INPUT_CAPTURE1
#pragma GCC poison SIG_OUTPUT_COMPARE1A
#pragma GCC poison SIG_OUTPUT_COMPARE1B
#pragma GCC poison SIG_OVERFLOW1
#pragma GCC poison SIG_OVERFLOW0
#pragma GCC poison SIG_SPI
#pragma GCC poison UART_RX_vect
#pragma GCC poison SIG_UART_RECV
#pragma GCC poison UART_UDRE_vect
#pragma GCC poison SIG_UART_DATA
#pragma GCC poison UART_TX_vect

 

#Poison #Poisoned

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Jan 26, 2018 - 09:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The implication of what Andy just showed is that if you have some old, out dated, legacy code that uses the old name and there's some reason you can't change the code then make sure the compiler is passed -D__AVR_LIBC_DEPRECATED_ENABLE__

 

BTW I wonder where you got the notion that it should be UART_TX_vect and not USART_TX_vect in the first place? Was it this page in the user manual perhaps?...

 

http://www.nongnu.org/avr-libc/u...

 

That table does appear to be wrong/out of date as it lists:

 

 

I guess if someone had the time/inclination this should be put on the AVR-LibC Bugzilla as a fault in the auto-generated Doxygen documentation.

 

EDIT: The error appears to be around line 604 in this:

 

http://svn.savannah.gnu.org/view...

 

(I thought the table in the documentation was somehow auto-generated from the ioXXX.h themselves but seemingly not - it's a hand edited table and clearly it's now out of date)

Last Edited: Fri. Jan 26, 2018 - 09:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm a bit surprised by this:

patchell wrote:
, but this problem has me stumped.
Without using Internet you should have been able to find the definition of UART_TX_vect on your own pc in the correct headerfile.

On my linux box it's in:

/usr/lib/avr/include/avr/iom8515.h

So next time try to follow the trail with the info you have.

 

This hardly ads anything to the posts below:

https://duckduckgo.com/html?q=%2...

https://www.avrfreaks.net/forum/a...

 

@clawson:

Most likely scenario would be porting an old program from a at90s8515 to an atmega8515.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Fri. Jan 26, 2018 - 10:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for the answer.  Sorry I caused such a ruckus.

-Jim
http://www.noniandjim.com
Analog and Digital Electronics
Music Synthesizers