UART interrupt causes reset seizures

Go To Last Post
72 posts / 0 new

Pages

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

You are looking at two different things here. You have checked the fuses; that is one thing. What the compiler is doing is something else. If the compiler doesn't know which device you are using, it might make some assumptions and generate code that is not valid for your device.

If you think education is expensive, try ignorance.

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

Quote:
I was talking about the version of AVR Studio, not WinAVR.

But I do not have AVR Studio installed... :|

Quote:
If the compiler doesn't know which device you are using, it might make some assumptions and generate code that is not valid for your device.

As I have said, the mcu type is correctly specified in the Makefile. Unless there's something else that I have to do in addition to that, I don't see how the compiler couldn't know what type of mcu I'm using.

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

Any answer to my

Quote:
All the clock fuses are, indeed, 0.
post above? Are you really running with the fuses on External Cock?

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

Oh my bad, they're all are set to 1. I forgot that unprogrammed = 1 and not 0. Just so there's no confusion, here's a screenshot of the window:

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

Is that for the slow crystal or the fast crystal? CKOPT is not programmed in the screenshot, but if this is for 16mhz, it needs to be checked (programmed).

If CKOPT was not programmed for 16mhz, I would think the usart would show problems with the clock by putting out at least some garbage when transmitting those '.' characters, or the reset character.

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

Another week wasted by a cheap programmer?...and what do you mean:

Quote:
I forgot that unprogrammed = 1 and not 0.
If you had read what it shows you it says that CHECKED means programmed, UNCHECKED means UNprogrammed. :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Hey what do you know, curtvm, it works! Programming CKOPT did the trick, I thought I got it right from the datasheet, but apparently not. Anyway now there's no more weirdness, I have a screw driver holding the spacebar down on my pc and the avr has been going continuously for about 10 minutes now. I must apologize for "wasting" so much time-- thank you everyone who helped me solve this! Now time to stick my original program on there and see if it works...

Edit: My original program now works great. A little head-banging was caused by me forgetting to declare some global variables that I was using in an ISR as volatile, but now it's all good. Thanks again, everyone!

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

Thank you for this very useful thread !
It helped me a lot to find why sometimes when receiving a bunch of caracters on the serial port of an Atmega644P, it was reset randomly.
The CKSEL was wrong, I changed it to use the fullswing with max CK and delay and it now it works perfectly.
Thanks !

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

Good Day, guys!

I also have this problem with my USART, on Atmega32a and also on Atmega1284p.
The problem is so:
On a random ISR(USART) controller goes to 0 point of program (not reset!!) thats why leds don't work

PORTA = MCUCSR;
MCUCSR = 0;

You already have MCUCSR=0!!!

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

If using GCC the most common route to 0 with MCUCSR=0 is via _bad_interrupt. See "catch-all" on this page of the manual:

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

So which IE bits are you setting in the UCSRB register?

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

Quote:

So which IE bits are you setting in the UCSRB register?

...or anywhere else?

I've got an idea. If the default for unused vector was an [R]CALL instead of an [R]JMP, then one could construct the <__bad_interrupt>: handler to determine the "come from" and figure out which unhandled vector fired.

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

Lee,

Such schemes are often proferred but how could that work? If you have:

vec1: JMP vec1_handler
vec2: JMP vec2_handler
etc.

(or the RJMP equivalent for <= 8K) then how do propose to make this:

vec1: CALL vec1_handler
vec2: CALL vec2_handler
etc.

You need to squeeze in RET's there aren't room for.

vec1: CALL vec1_handler
???: RET
vec2: CALL vec2_handler
???: RET
etc.

To my mind the only way to catch the "which one is broken?" thing when the vector table is as tight as it is would be:

ISR(INT0_vect) {
  // this one
}
ISR(INT1_vect) {
  // no this one
}
etc.

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

Quote:

You need to squeeze in RET's there aren't room for.

No, you don't need to squeeze anything; no RET needed--you are never going to come back because the "bad interrupt" handler that is called is never going to return anywhere.

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

Good point ;-)

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

Depending on how you want to do bad-interrupt handling:

A. Ending with a [R]JMP 0: Do what you will; trash GP registers; don't worry about SREG;don't worry about stack contents. Probably get the "come from" address by popping from stack. Manipulate a bit to get the vector number. "Log" somewhere. If the app had room, I might put into an EEPROM array indexed by "bad interrupt count". If convenient, maybe a timestamp of runtime hours or similar.

B. Log-and-continue: Preserve SREG and GP registers. Leave stack intact. Pop off offending address; log as desired. As with a normal ISR, then restore GP registers; restore SREG; end with RETI.

Now, the "pop off offending address" gets tricky, as one generally would push registers and SREG contents first thing in an ISR.

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

As we're in the GCC forum then to achieve this you are going to need -nostartfiles and replace the default gcrt1.S (as it's firmly of the opinion that the vectors are XJMPs). So if you are doing that you might as well use a myCrt.S or something, put XCALLs at the vectors all pointing to a local handler that just does the (SP) stuff and stops - so no worries about working your way around ISR prologues as you just implement the raw handler that can identify who called it. No need for any of that messy C stuff.

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

Quote:

No need for any of that messy C stuff.

Whether C or ASM, approach A. requires less housekeeping. Depends on the app.

I don't know if I'll ever do it (in GCC or CV), but a tucked-away log of some kind might be useful in some apps. One could even have a mask with one bit for each vector. Then at least you could see if >>any<< were ever hit, even if one decides to do "log and continue".

An analogy would be to have (as I do) logged reset counts; reasons; and uptime counter (time between). It is useful to have this info from time-to-time. Now, one of these controller series has log files that are uploaded periodically and cycle reports generated. This is during normal operation. These can be examined for "watchdog", and/or "no cause" (which would be runaway code or, indeed, uncaught vector).

An excerpt from log report from a site with power problems. "Normal" daily log-file rollover lines omitted. When each log file is created (after each midnight, and after each restart, and after each SD-card fault), the uptime and last restart cause for the controller is put into the log file header info:

...
C:\OptiData\SEQDATA\LOG1308\L130805A.LOG  (reset cause 1 (Power On ), uptime 211 hours)
            Created: 8/5/2013 12:00:02 AM
C:\OptiData\SEQDATA\LOG1308\L130805B.LOG  (reset cause 3 (BrownOut ), uptime 0 hours)
            Created: 8/5/2013 1:18:03 AM
C:\OptiData\SEQDATA\LOG1308\L130805C.LOG  (reset cause 3 (BrownOut ), uptime 0 hours)
            Created: 8/5/2013 4:18:21 AM
C:\OptiData\SEQDATA\LOG1308\L130805D.LOG  (reset cause 1 (Power On ), uptime 0 hours)
            Created: 8/5/2013 8:18:33 AM
C:\OptiData\SEQDATA\LOG1308\L130806B.LOG  (reset cause 1 (Power On ), uptime 0 hours)
            Created: 8/6/2013 8:34:11 AM
C:\OptiData\SEQDATA\LOG1308\L130806C.LOG  (reset cause 3 (BrownOut ), uptime 0 hours)
            Created: 8/6/2013 2:36:55 PM
C:\OptiData\SEQDATA\LOG1308\L130807A.LOG  (reset cause 3 (BrownOut ), uptime 9 hours)
            Created: 8/7/2013 12:00:02 AM
C:\OptiData\SEQDATA\LOG1308\L130807B.LOG  (reset cause 1 (Power On ), uptime 0 hours)
            Created: 8/7/2013 2:33:50 AM
C:\OptiData\SEQDATA\LOG1308\L130808A.LOG  (reset cause 1 (Power On ), uptime 21 hours)
            Created: 8/8/2013 12:00:02 AM
C:\OptiData\SEQDATA\LOG1308\L130808B.LOG  (reset cause 3 (BrownOut ), uptime 0 hours)
            Created: 8/8/2013 8:12:52 AM
C:\OptiData\SEQDATA\LOG1308\L130808C.LOG  (reset cause 3 (BrownOut ), uptime 0 hours)
            Created: 8/8/2013 8:14:12 AM
C:\OptiData\SEQDATA\LOG1308\L130808D.LOG  (reset cause 3 (BrownOut ), uptime 0 hours)
            Created: 8/8/2013 8:21:05 AM
C:\OptiData\SEQDATA\LOG1308\L130809A.LOG  (reset cause 3 (BrownOut ), uptime 15 hours)
            Created: 8/9/2013 12:00:02 AM
...
C:\OptiData\SEQDATA\LOG1308\L130812A.LOG  (reset cause 3 (BrownOut ), uptime 87 hours)
            Created: 8/12/2013 12:00:02 AM
C:\OptiData\SEQDATA\LOG1308\L130812B.LOG  (reset cause 1 (Power On ), uptime 0 hours)
            Created: 8/12/2013 2:59:31 AM
C:\OptiData\SEQDATA\LOG1308\L130812C.LOG  (reset cause 1 (Power On ), uptime 0 hours)
            Created: 8/12/2013 3:02:28 AM
C:\OptiData\SEQDATA\LOG1308\L130812D.LOG  (reset cause 1 (Power On ), uptime 0 hours)
            Created: 8/12/2013 3:07:06 AM
C:\OptiData\SEQDATA\LOG1308\L130812E.LOG  (reset cause 3 (BrownOut ), uptime 0 hours)
            Created: 8/12/2013 3:09:02 AM
C:\OptiData\SEQDATA\LOG1308\L130812F.LOG  (reset cause 1 (Power On ), uptime 0 hours)
            Created: 8/12/2013 3:11:41 AM
C:\OptiData\SEQDATA\LOG1308\L130812G.LOG  (reset cause 3 (BrownOut ), uptime 0 hours)
            Created: 8/12/2013 4:51:27 AM
C:\OptiData\SEQDATA\LOG1308\L130812H.LOG  (reset cause 1 (Power On ), uptime 0 hours)
            Created: 8/12/2013 6:01:58 AM
C:\OptiData\SEQDATA\LOG1308\L130813A.LOG  (reset cause 1 (Power On ), uptime 17 hours)
            Created: 8/13/2013 12:00:02 AM
C:\OptiData\SEQDATA\LOG1308\L130813B.LOG  (reset cause 1 (Power On ), uptime 0 hours)
            Created: 8/13/2013 11:03:39 AM
C:\OptiData\SEQDATA\LOG1308\L130814A.LOG  (reset cause 1 (Power On ), uptime 12 hours)
            Created: 8/14/2013 12:00:02 AM
C:\OptiData\SEQDATA\LOG1308\L130814B.LOG  (reset cause 1 (Power On ), uptime 18 hours)
            Created: 8/14/2013 5:20:53 AM
C:\OptiData\SEQDATA\LOG1308\L130814C.LOG  (reset cause 1 (Power On ), uptime 19 hours)
            Created: 8/14/2013 6:30:12 AM
...

So if a mechanism such as is being discussed were implemented, the retained "come from" would be available to add to this report when reset cause is "none".

(the above excerpt was useful in determining the situation at the end-customer field installation)

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

I think that the call bad_isr subject deserves its own thread,
so I started one: https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1175462#1175462

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

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

Hi All FYI, 

 

I Had this same issue on the atmega644P which I was only able to fix with the help of this forum thread. 

 

For the atmega644P I set the SUT_CKSEL fuse options to Full Swing Oscillator; Start-up time: 16K CK + 65mS; Crystal Osc; slow rising power.

 

I am running the micro at 20MHz which is the upper limit of the device but from the datasheet, any clock frequency above 16MHz needs to use the Full Swing Oscillator option.

 

Regards,

Graham

Arduinos are cheating. Discuss

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

GLong wrote:
any clock frequency above 16MHz needs to use the Full Swing Oscillator option
I'm pretty sure you'll find it's anything over 8MHz that needs full swing.

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

clawson wrote:

GLong wrote:

any clock frequency above 16MHz needs to use the Full Swing Oscillator option

 

I'm pretty sure you'll find it's anything over 8MHz that needs full swing.

 

8MHz is referenced a few time yeah, I was going by Table 6-3 of this datasheet ( http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega164P-324P-644P-Data-Sheet-40002071A.pdf ) which goes up to 16MHz for the low power crystal Oscillator.

 

Arduinos are cheating. Discuss

Pages