Clock initially worked, now does not
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
-
- Posts: 12151
- Joined: Thu Apr 06, 2006 4:21 pm
Re: Clock initially worked, now does not
yah...it seems unlikely but it could be the chip or pin is somehow bonked.
-
- Posts: 25
- Joined: Wed Nov 11, 2009 10:35 am
Re: Clock initially worked, now does not
Guess I ordered mega328's instead. I tried flashing with the Sept30 firmware one and putting it in, no beep. bummer.
-
- Posts: 61
- Joined: Mon Oct 26, 2009 1:21 am
Re: Clock initially worked, now does not
Did you change MCU= at the top of the Makefile?azurewraith wrote:Guess I ordered mega328's instead. I tried flashing with the Sept30 firmware one and putting it in, no beep. bummer.
-
- Posts: 25
- Joined: Wed Nov 11, 2009 10:35 am
Re: Clock initially worked, now does not
I ran 'make program' and that did not flash the chip correctly because the makefile needed to be changed. So I just ran avrdude with the correct parameters to flash iv.hex. I'm assuming I might be in error state because I didn't change the target for the compilation. I will try that when I can get back to the board.
-
- Posts: 25
- Joined: Wed Nov 11, 2009 10:35 am
Re: Clock initially worked, now does not
If MCU=atmega168, the code compiles fine... but when I change it to atmega328p it doesn't compile anymore. Had no idea that switching targets like that was such a big deal *sigh*
Any ideas?
Compiling: iv.c
avr-gcc -c -mmcu=atmega328p -I. -g -Os -funsigned-char -funsigned-bitfields -fpa
ck-struct -fshort-enums -Wall -Wstrict-prototypes -DF_CPU=8000000 -std=gnu99 -D
TXMODE= iv.c -o iv.o
In file included from iv.c:35:
fonttable.h:30: warning: pointer targets in initialization differ in signedness
fonttable.h:44: warning: pointer targets in initialization differ in signedness
iv.c:70: warning: pointer targets in initialization differ in signedness
iv.c:78: warning: pointer targets in initialization differ in signedness
iv.c:124: warning: 'SIG_OVERFLOW0' appears to be a misspelled signal handler
iv.c:186: warning: 'SIG_PIN_CHANGE2' appears to be a misspelled signal handler
iv.c: In function 'SIG_PIN_CHANGE2':
iv.c:190: error: 'PD5' undeclared (first use in this function)
iv.c:190: error: (Each undeclared identifier is reported only once
iv.c:190: error: for each function it appears in.)
iv.c:211: error: 'PD4' undeclared (first use in this function)
iv.c: At top level:
iv.c:243: warning: 'SIG_PIN_CHANGE0' appears to be a misspelled signal handler
iv.c: In function 'SIG_PIN_CHANGE0':
iv.c:245: error: 'PB0' undeclared (first use in this function)
iv.c: At top level:
iv.c:364: warning: 'SIG_INTERRUPT0' appears to be a misspelled signal handler
iv.c: In function 'SIG_INTERRUPT0':
iv.c:366: error: 'PD2' undeclared (first use in this function)
iv.c: At top level:
iv.c:376: warning: 'SIG_COMPARATOR' appears to be a misspelled signal handler
iv.c: In function 'SIG_COMPARATOR':
iv.c:381: error: 'PD3' undeclared (first use in this function)
iv.c:382: error: 'PB5' undeclared (first use in this function)
...
Any ideas?
Compiling: iv.c
avr-gcc -c -mmcu=atmega328p -I. -g -Os -funsigned-char -funsigned-bitfields -fpa
ck-struct -fshort-enums -Wall -Wstrict-prototypes -DF_CPU=8000000 -std=gnu99 -D
TXMODE= iv.c -o iv.o
In file included from iv.c:35:
fonttable.h:30: warning: pointer targets in initialization differ in signedness
fonttable.h:44: warning: pointer targets in initialization differ in signedness
iv.c:70: warning: pointer targets in initialization differ in signedness
iv.c:78: warning: pointer targets in initialization differ in signedness
iv.c:124: warning: 'SIG_OVERFLOW0' appears to be a misspelled signal handler
iv.c:186: warning: 'SIG_PIN_CHANGE2' appears to be a misspelled signal handler
iv.c: In function 'SIG_PIN_CHANGE2':
iv.c:190: error: 'PD5' undeclared (first use in this function)
iv.c:190: error: (Each undeclared identifier is reported only once
iv.c:190: error: for each function it appears in.)
iv.c:211: error: 'PD4' undeclared (first use in this function)
iv.c: At top level:
iv.c:243: warning: 'SIG_PIN_CHANGE0' appears to be a misspelled signal handler
iv.c: In function 'SIG_PIN_CHANGE0':
iv.c:245: error: 'PB0' undeclared (first use in this function)
iv.c: At top level:
iv.c:364: warning: 'SIG_INTERRUPT0' appears to be a misspelled signal handler
iv.c: In function 'SIG_INTERRUPT0':
iv.c:366: error: 'PD2' undeclared (first use in this function)
iv.c: At top level:
iv.c:376: warning: 'SIG_COMPARATOR' appears to be a misspelled signal handler
iv.c: In function 'SIG_COMPARATOR':
iv.c:381: error: 'PD3' undeclared (first use in this function)
iv.c:382: error: 'PB5' undeclared (first use in this function)
...
-
- Posts: 12151
- Joined: Thu Apr 06, 2006 4:21 pm
Re: Clock initially worked, now does not
heh, you've found the annoying '328p bug in avr-gcc
-
- Posts: 25
- Joined: Wed Nov 11, 2009 10:35 am
Re: Clock initially worked, now does not
rawr. I am a master of encountering known issues and messing up perfectly good kits ^_^.
- mike31416
- Posts: 126
- Joined: Wed Aug 26, 2009 12:06 pm
Re: Clock initially worked, now does not
I ran into the same issues when porting to the Arduino Duemilanove. I put #ifdef around the interrupt names and did the same to create defines for the port defs. I have a copy of the code here that you could use for reference. Ignore the other changes because they are particular to the duemilanove port (timing changes).
http://forums.adafruit.com/viewtopic.php?f=41&t=12948
Mike
http://forums.adafruit.com/viewtopic.php?f=41&t=12948
Mike
-
- Posts: 25
- Joined: Wed Nov 11, 2009 10:35 am
Re: Clock initially worked, now does not
Thanks Mike, those changes were exactly what avr-gcc needed.
With an m328p freshly flashed firmware in hand I tried to see if I could init the uC...no dice. So I removed R2 again to see if I could at least get the thing to boot. It beeped but it was a really long beep , but the boost diode didn't have 50V so I put the old chip back in, got the normal beep but only 9V or 14V on the boost diode lead depending on when you plugged it in. So now it looks like I'm worse off. Bah.
With an m328p freshly flashed firmware in hand I tried to see if I could init the uC...no dice. So I removed R2 again to see if I could at least get the thing to boot. It beeped but it was a really long beep , but the boost diode didn't have 50V so I put the old chip back in, got the normal beep but only 9V or 14V on the boost diode lead depending on when you plugged it in. So now it looks like I'm worse off. Bah.
-
- Posts: 25
- Joined: Wed Nov 11, 2009 10:35 am
Re: Clock initially worked, now does not
Any other suggestions? I'm out of ideas. Can I send it back if it does not start working again?
-
- Posts: 12151
- Joined: Thu Apr 06, 2006 4:21 pm
Re: Clock initially worked, now does not
we dont accept returns of assembled kits. you should go with our suggestion to forget about the battery detection circuitry and remove the resistor and take out the battery. use the microcontroller that came with the kit, do the tests you had gone through before. if youre going to program a new chip, dont complicate it by picking a different one.
-
- Posts: 25
- Joined: Wed Nov 11, 2009 10:35 am
Re: Clock initially worked, now does not
Interesting.
I put everything back to its previous boosting state (no R2, original chip, no batt, no vfd) and it is beeping but not boosting to 50V. I've mentioned this already. The thing is not even in a working state, and I only saw it ever work for like 2h. Could that be my fault? Sure. Do I really want to spend another week debugging it? No. Seems as though it is never getting out of low power mode b/c the chip is running at 3.3V. I'd happily deal without battery backup if I could just get back to that state.
The whole thing with the other chip was to see if somehow I blew out the analog comparator on the chip that was included, that's it. I was working with what I had.
Could I ship the assembled kit to your lab for a post mortem? I really do not want to have thrown $70 down the toilet.
I put everything back to its previous boosting state (no R2, original chip, no batt, no vfd) and it is beeping but not boosting to 50V. I've mentioned this already. The thing is not even in a working state, and I only saw it ever work for like 2h. Could that be my fault? Sure. Do I really want to spend another week debugging it? No. Seems as though it is never getting out of low power mode b/c the chip is running at 3.3V. I'd happily deal without battery backup if I could just get back to that state.
The whole thing with the other chip was to see if somehow I blew out the analog comparator on the chip that was included, that's it. I was working with what I had.
Could I ship the assembled kit to your lab for a post mortem? I really do not want to have thrown $70 down the toilet.
-
- Posts: 12151
- Joined: Thu Apr 06, 2006 4:21 pm
Re: Clock initially worked, now does not
Lets try to get it working again, after all it did before. Please follow our instructions and do not go off and program chips or anything, ok? It is possible to damage the kit by programming a chip incorrectly. If the chip is completely )@*$#@'d then you can buy one from us
First, Why is the chip running at 3.3V? Are you checking the 7805 power supply? Is the fuse very hot?
First, Why is the chip running at 3.3V? Are you checking the 7805 power supply? Is the fuse very hot?
-
- Posts: 25
- Joined: Wed Nov 11, 2009 10:35 am
Re: Clock initially worked, now does not
The innermost pin (from the edge of the board) of the regulator is 3.3V. The fuse nor the regulator is getting hot at all. Every time I touch a soldering iron to the board the behavior changes, which is pretty weird. The only work I did to the board was to add back in R2 and test the 328p, once I took R2 back out things were awry again.
I can order some mega168p's, that's fine. Maybe it would help if I said that I do hardware/software engineering/debug as a full time job. I know that the debug process involves some 'tweak a knob' see if the behavior changes, frankly I know that reprogramming my atmega168 chip that came with the clock is a big mistake unless I had another chip just like it. Given the voltages that I was seeing on the analog comparator pin given R2 being populated, the chip should have worked properly and detected the internal bandgap differential. That's why I wanted to try a different chip. i will try an atmega168p then.
You have sort of got me at a loss here, I have followed the guidance given to me to the letter. There has been nothing new presented in this thread that I have not checked already. When I say that the board is not working, I mean that I 95% of the time I say the board is not functioning, have the original 168p in there and have been testing that.
I can order some mega168p's, that's fine. Maybe it would help if I said that I do hardware/software engineering/debug as a full time job. I know that the debug process involves some 'tweak a knob' see if the behavior changes, frankly I know that reprogramming my atmega168 chip that came with the clock is a big mistake unless I had another chip just like it. Given the voltages that I was seeing on the analog comparator pin given R2 being populated, the chip should have worked properly and detected the internal bandgap differential. That's why I wanted to try a different chip. i will try an atmega168p then.
You have sort of got me at a loss here, I have followed the guidance given to me to the letter. There has been nothing new presented in this thread that I have not checked already. When I say that the board is not working, I mean that I 95% of the time I say the board is not functioning, have the original 168p in there and have been testing that.
-
- Posts: 12151
- Joined: Thu Apr 06, 2006 4:21 pm
Re: Clock initially worked, now does not
Don't worry, we can get it working again. Its great that you are experienced in hardware & your soldering skills are top notch! Thats helpful when debugging a project. Some people have no experience at all, which can cause problems. Given that we have no way of knowing what experience levels our customers have, we have found that its best to debug kits step by step. Usually the problem is not the chip. For example, if you arent getting 5V from the regulator, it implies that there is a major problem that is unlikely to be solved by any chip reprogramming. We need to get the kit back to a 'working' state with a 5V supply before we can continue (possibly with a new chip, etc).
So lets get the voltage regulator working, since that is the most important thing right now. if it isnt working that means something is very amiss.
Gently remove the microcontroller. Check for bent pins since it can happen when removing/inserting chips. the VFD driver should already be out
Now, measure the voltage coming out of your power supply: http://www.ladyada.net/learn/multimeter/voltage.html
we're assuming you're using the power supply that came with the kit, if you're not using that, get the matching power supply.
What is the voltage on the tip power supply with respect to the barrel? it should be 9V-14V DC
Second, since you do this for a job, do you have access to a scope?
So lets get the voltage regulator working, since that is the most important thing right now. if it isnt working that means something is very amiss.
Gently remove the microcontroller. Check for bent pins since it can happen when removing/inserting chips. the VFD driver should already be out
Now, measure the voltage coming out of your power supply: http://www.ladyada.net/learn/multimeter/voltage.html
we're assuming you're using the power supply that came with the kit, if you're not using that, get the matching power supply.
What is the voltage on the tip power supply with respect to the barrel? it should be 9V-14V DC
Second, since you do this for a job, do you have access to a scope?
Please be positive and constructive with your questions and comments.