| Author |
Message |
|
|
 Posted: Jun 29, 2012 - 08:20 PM |
|
Joined: Jul 18, 2005
Posts: 62351
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
People contribute here because they like to be helpful. Nothing more. You can choose to take advice or you can ignore it's your choice.
Often a lateral suggestion will lead the OP on a path they might never have thought of exploring. Unless of course they already know everything already that is. |
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 04:06 PM |
|
Joined: May 28, 2012
Posts: 91
|
|
I didn't say I know everything... It's just irritating to be told to use someone else's stuff instead of trying things yourself. Sorry for the outburst, this problem is driving me insane.
Long story short, I tried Fleury's UART code (although it has no support for my atmega, so I had to change a lot of register names and such) with same resetting problem.
I then got Procyon UART with buffer code, and again, the problem remains. I wrote an ISR for every interrupt that exists in the iom1284p list. I also added ISR(BADISR_vect), but perhaps that's incorrect syntax?
The problem seems to occur when I do this:
Code:
uint8_t myReceivedByte;
int check;
while(1)
{
check = uartReceiveByte( &myReceivedByte );
if (check == TRUE)
{
uartSendByte('1');
}
}
However, this is okay:
Code:
while(1){uartSendByte('8');}
It resets after a random number of received characters. Am I somehow running out of memory or something? I don't seem to be able to simulate this problem, however. Or at least I don't know how.
Can it reset due to framing error? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 04:28 PM |
|
Joined: Jul 18, 2005
Posts: 62351
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
I also added ISR(BADISR_vect), but perhaps that's incorrect syntax?
Depends on exactly how you did it but something like:
Code:
ISR(BADISR_vect) {
while(1); // don't go away
}
should do the trick if you have an on chip debugger. You then put a break point on the while(1) loop and wait. Sadly all this tells you is that it is an un-handled interrupt that is occurring but not which one. If you don't have a debugger do something like:
Code:
ISR(BADISR_vect) {
DDRx = (1 << n);
while(1) {
PORTX ^= (1 << n);
_delay_ms(100);
}
}
(fill in "x" and "n" as appropriate for your LED) then an LED will flash if the unhandled condition occurs. Or as you have UART working:
Code:
ISR(BADISR_vect) {
uartWriteString("Bad interrupt");
while(1);
}
But before assuming it is an unhandled vector that leads to resets start by finding out what the reset cause actually is. Near the top of main() take a copy of MCUSR and either feed it up the UART or write it into EEPROM. Then set that register to 0. After the next reset occurs either see what came out of the UART or what was programmed into EEPROM (read it out using your ISP) and the bit(s) that are set will tell you what kind of reset is occuring. Only if the register is apparently 0x00 should you then consider that it might be the BADISR_vect thing. If it is that then probably quickest is to add ISR()s for every ISR source the chip has and have each one do something like sending a unique code up UART or to an LCD or out to 8 LEDs on a PORT or something to identify which one is occurring. |
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 04:52 PM |
|
Joined: May 28, 2012
Posts: 91
|
|
|
clawson wrote:
But before assuming it is an unhandled vector that leads to resets start by finding out what the reset cause actually is. Near the top of main() take a copy of MCUSR and either feed it up the UART or write it into EEPROM. Then set that register to 0. After the next reset occurs either see what came out of the UART or what was programmed into EEPROM (read it out using your ISP) and the bit(s) that are set will tell you what kind of reset is occuring. Only if the register is apparently 0x00 should you then consider that it might be the BADISR_vect thing. If it is that then probably quickest is to add ISR()s for every ISR source the chip has and have each one do something like sending a unique code up UART or to an LCD or out to 8 LEDs on a PORT or something to identify which one is occurring.
I made a copy of MCUSR, put it into a character, and added 32 go get into the letter region.
What came out was an apostrophe -> ', which converts back (-32) to 7, bit 3 of MCUSR.
This appears to be the watchdog timer reset. Is this logical? This would explain why my silly field of ISRs doesn't work.
Thanks a lot for the idea! I don't know when I'm enabling it (simulations says I'm not), but maybe I'll just disable it in the main and see what happens. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 05:09 PM |
|
Joined: Jul 18, 2005
Posts: 62351
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
to 7, bit 3 of MCUSR.
7 is bits 2, 1 and 0 all set. That suggests Brown Out and External and Power on.
But the way you have to use MCUSR is to make sure the register is 0 then let the reset occur then take a copy. Without clearing it the bits will accumulate after various kinds of reset.
WDRF would have been 8 or character '('
Cliff |
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 05:29 PM |
|
Joined: May 28, 2012
Posts: 91
|
|
|
clawson wrote:
Quote:
to 7, bit 3 of MCUSR.
7 is bits 2, 1 and 0 all set. That suggests Brown Out and External and Power on.
But the way you have to use MCUSR is to make sure the register is 0 then let the reset occur then take a copy. Without clearing it the bits will accumulate after various kinds of reset.
WDRF would have been 8 or character '('
Cliff
Whoa, that was a major derp on my part. Excuse me. 
Anyway. So can I do this then?
Code:
ph1 = MCUSR;
MCUSR = 0x00;
I store MCUSR value in ph1, then print it to USART later. The datasheet says MCUSR is cleared by writing zeroes.
I did this (because I'm impatient), and the result is now 0 (I get a space - 32, or !-33). But that would suggest ISR again? 
Pressing the reset button gives 2, which is external, right? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 06:19 PM |
|
Joined: May 28, 2012
Posts: 91
|
|
I put a print to UART function into every ISR. Apparently a lot of them fire. By far the majority is due to INT2 and INT1. I saw a few Timer related interrupts (like Timer3_Capture), and a few that reset without an ISR (so I'm missing something?).
I'm not sure why they are all active? Should I go through them individually at the beginning and disable everything? I would have thought it'd be by default. |
Last edited by mewakitty on Jul 04, 2012 - 06:20 PM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 06:20 PM |
|
Joined: Sep 04, 2002
Posts: 21272
Location: Orlando Florida
|
|
| Just put a bfc on vcc. That will get rid of the brownout. HW fix for SW prob. |
_________________
Imagecraft compiler user
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 06:48 PM |
|
Joined: May 28, 2012
Posts: 91
|
|
bob, do you think what's happening is a result of brownout? I put a cap there, but I don't think it helped (or I did it wrong).
More news, I did this, to try to disable INT2 and INT1:
Code:
EIMSK = 0x00;
PCICR = 0x00;
But it doesn't work still. What in the world am I doing that enables all this stuff in the loop?
But that still doesn't help. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 07:10 PM |
|
Joined: Feb 12, 2005
Posts: 16323
Location: Wormshill, England
|
|
|
Quote:
Long story short, I tried Fleury's UART code (although it has no support for my atmega, so I had to change a lot of register names and such) with same resetting problem.
I then got Procyon UART with buffer code, and again, the problem remains. I
I would choose one or the other. Then make sure that I get the mega1284P port correct.
Then investigate the Watchdog. INT0, INT1 and PCINTn interrupts.
I am assuming that you have a proper pcb with stable power supply and proper capacitors. And you have set fuses properly.
David. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 08:07 PM |
|
Joined: May 28, 2012
Posts: 91
|
|
|
david.prentice wrote:
Quote:
Long story short, I tried Fleury's UART code (although it has no support for my atmega, so I had to change a lot of register names and such) with same resetting problem.
I then got Procyon UART with buffer code, and again, the problem remains. I
I would choose one or the other. Then make sure that I get the mega1284P port correct.
Of course. I am using the Procyon one right now. I went through the registers and pin names, I think they're correct.
Quote:
Then investigate the Watchdog. INT0, INT1 and PCINTn interrupts.
Don't know how to investigate further. Basically what I said recently is what I know is happening. I don't know why anything is happening.
Watchdog isn't firing, that was a mistake on my part. I am getting random interrupts going off (mostly INT2), but I cannot tell why. I don't know when they get enabled. If I try to disable them in the main (as I showed above), they fire anyways (so something enables them later).
Quote:
I am assuming that you have a proper pcb with stable power supply and proper capacitors. And you have set fuses properly.
I am on a breadboard. Probably as stable of a power supply as I can get. 1uF capacitors on Vcc pins.
Fuses: extended 0xFF, high 0xD9, low 0xFF. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 08:38 PM |
|
Joined: Sep 04, 2002
Posts: 21272
Location: Orlando Florida
|
|
| There is a checklist of schtuff to look for in a breadboard setup. AVCC needs to attach to VCC. You need .1uf bypass caps in addition to the electrolytic caps, because they suck up the hi freq spikes better. All gnds need to be attached to the gnd bus. How about showing us a nice picture of the 1284 setup? I'm sure someone will pipe up if they dont like the looks of something. |
_________________
Imagecraft compiler user
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 09:15 PM |
|
Joined: Jul 18, 2005
Posts: 62351
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
I am getting random interrupts going off (mostly INT2), but I cannot tell why.
Can only be because INT2 is set in EIMSK. Could you have a rogue pointer that is leading to a write through to the address of EIMSK? I'd add some code that watches EIMSK and if it is ever seen to have unexpected values STOP. |
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 09:17 PM |
|
Joined: Feb 12, 2005
Posts: 16323
Location: Wormshill, England
|
|
As Uncle Bob says, 1uF electrolytics are no good for digital circuits. You need 100nF ceramic capacitors. You also need reasonable physical layout with 20MHz.
From your other thread, the 20MHz clock will be absolutely perfectly stable. And quite capable of producing 115200 baud with U2X. There is little point in going for high bauds anyway. 9600 baud does me fine for any human interaction.
Your Procyon example program should work 100% perfectly. It will also be efficient for CPU cycles.
If you are having difficulties, post a link to your code. (or paste it in a message)
David. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 09:19 PM |
|
Joined: May 28, 2012
Posts: 91
|
|
Here you go. I forgot to switch the oscillator back before I took the picture, but the connections are the same nonetheless.
Let the criticism begin! I tried to color code it, but it's hard (sorry). In general orange is Vcc and black is Vss. Also, the reset button cap is missing because... I don't know where it went. It works without it.
Green flat caps are 0.1uF, yellow "flat" is 10uF, blue bucket cap is 1uF, black buckets are 10uF. The lone resistor is 100k, I think.
Vcc rail measures at 4.97V.
 |
|
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 09:25 PM |
|
Joined: May 28, 2012
Posts: 91
|
|
|
clawson wrote:
Quote:
I am getting random interrupts going off (mostly INT2), but I cannot tell why.
Can only be because INT2 is set in EIMSK. Could you have a rogue pointer that is leading to a write through to the address of EIMSK? I'd add some code that watches EIMSK and if it is ever seen to have unexpected values STOP.
The only pointer I'm aware of that could wander off is the buffer pointer. Although... I'm not sure. Anyway, I will add some code to watch EIMSK.
david.prentice wrote:
As Uncle Bob says, 1uF electrolytics are no good for digital circuits. You need 100nF ceramic capacitors. You also need reasonable physical layout with 20MHz.
Okay, I will find some 100nF caps.
Edit: I found them, they're in the shot. Should I remove the teal colored 1uF one?
Quote:
From your other thread, the 20MHz clock will be absolutely perfectly stable. And quite capable of producing 115200 baud with U2X. There is little point in going for high bauds anyway. 9600 baud does me fine for any human interaction.
Yes, I am trying to work at 19200 right now, it's the same as 9600 behavior wise.
Quote:
Your Procyon example program should work 100% perfectly. It will also be efficient for CPU cycles.
Well, given that I had problems with Fleury's and this one, I think it is definitely something I am causing. A loose wire, a bad connection (or bad design, eep).
[quote]If you are having difficulties, post a link to your code. (or paste it in a message).[quote]
I will by the end of the day (2 hours) if I don't get it working. For now I will try the EIMSK thing and see what happens there. Plus double check the code I wrote in the main. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 10:05 PM |
|
Joined: Sep 04, 2002
Posts: 21272
Location: Orlando Florida
|
|
| Looks to me like the oscillator is plugged into xtal2. Datasheet says on page 35 to use xtal1. Tell me if I found the problem. |
_________________
Imagecraft compiler user
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 10:17 PM |
|
Joined: May 28, 2012
Posts: 91
|
|
|
bobgardner wrote:
Looks to me like the oscillator is plugged into xtal2. Datasheet says on page 35 to use xtal1. Tell me if I found the problem.
Yes! 
I wonder how long it's been like that for...  I think I assumed (never assume) XTAL1 would be before XTAL2 in pin numbering. Hmm.
I'm surprised anything worked at all! Do you have any ideas how this could result in resetting? I'm honestly curious now how the uC did anything, especially send things correctly to UART.
However, the 115200 baud rate is still giving me problems. I will get a crystal with a baud frequency and see if that helps.
Any other comments on the circuit layout? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 10:28 PM |
|
Joined: Feb 12, 2005
Posts: 16323
Location: Wormshill, England
|
|
You have posted an excellent photo. I wish that others could be as neat as you. And if they could use several different wire colours like you have !!
Uncle Bob's razor sharp eyesight spotted the XTAL2 immediately.
You should be ok with the 100nF caps. The blue cap is fine too.
Double check the Procyon code. Everything will be better after a nice cup of tea.
David. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2012 - 11:16 PM |
|
Joined: Sep 04, 2002
Posts: 21272
Location: Orlando Florida
|
|
| I have heard that the 'old style' max232s that use the 1uf caps dont run faster than 115200, but the newer ones run the charge pump faster, use .1uf caps, and probably run faster. Check the datasheet. |
_________________
Imagecraft compiler user
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
