Forum Index > Projects > Clock Kits
 Working Clock - Suddenly 100% Dark
 |  Printable Version
By: preiner (offline) on Monday, January 10 2011 @ 10:39 AM PST (Read 4618 times)  
preiner

New unit was working fine. I was just setting the initial time and brightenss when it went 100% dark.

Using DVM:

* JP1 and PIC has 5v (power seems fine everywhere)

* PIC pin 1 is high

* All 3 switches read okay

* FREQ mode of DVM across crystal reads 100Khz and then climbs slowly. Im worried that my DVM is loading the crystal or Im not measuring correctly.

I do have a scope I can drag out if this is the only suggested method to verify it.

* I have initiated a reset after a full power cycle (no help)

* I have left power off for 12 hours

My next thought was to reburn the chip. I suspect bad eeprom data or code corruption.

I downloaded env #17 and date/time library for Win 7 x64

I installed USB/Serial cable provided with kit and Win 7 had drivers for it. It is set to 9600,N,8

The Beady2 sketch verifies fine but I cannot upload.

I get a not in sync error and a protocol error.

The serial port is verified at COM4 and board type is set to Arduino Diecimila with ATmega168

Lastly I tried to reburn the boot loader using AVR ISP (I presume thats what this USB cable emulates) but that hangs forever without any messages.

Can someone suggest the next steps to check? Please provide a laundry list to minimize thread turnaround.


I can dig out the scope if needed and I am proficient coder. Its that Im not sure my board settings and USB cable are set correctly.














Forum Apprentice
Apprentice

Status: offline

Registered: 01/10/11
Posts: 6

Profile Email    
   
By: squall_line (offline) on Monday, January 10 2011 @ 11:54 AM PST  
squall_line

Are you using the Chronodot option?

Are you sure that you didn't short something out or knock something loose when you were setting the clock?

According to the build instructions, there are different ways to "brick" the clock, by getting it set to a mode with all of the LEDs turned off. It sounds like you may have inadvertently done this.

When you said that you "initiated a reset", do you mean the reset procedure in the manual, which states to power cycle the clock and hold down the + and - buttons for 5 seconds total?

I don't know that re-writing the chip is necessarily the best course of action in this case. It sounds like it's working fine, but that it's set in an "All Dark" mode of some kind. I would recommend looking through all of the "Setting options" pages in the manual again just to be sure.


Forum Mad Scientist
Mad Scientist

Status: offline

Registered: 04/13/10
Posts: 96
Iowa, USA

Profile Email    
   
By: Windell (offline) on Monday, January 10 2011 @ 12:17 PM PST  
Windell

It sounds like you've been thorough and checked most of the common things that can go wrong.

>PIC pin 1 is high

I presume that you mean AVR. (If you've built our bulbdial clock with a PIC, that's an unsupported mod.)

> FREQ mode of DVM across crystal reads 100Khz and then climbs slowly.

You probably can't get a sensible reading of the crystal from a DVM, so don't sweat that one. Make sure that the solder connections by the crystal and its caps, along with the nearby pins on the chip, all look pristine.

>The Beady2 sketch verifies fine but I cannot upload.

Make sure that power is on when you try to program.


>Lastly I tried to reburn the boot loader using AVR ISP (I presume thats what this USB cable emulates) but that hangs forever without any messages.

I'm not sure what you mean that you tried ("I tried to reburn the boot loader using AVR ISP" ). It *is* possible to use the FTDI USB-TTL cable as a "bitbang" ISP programmer, where you hook up it up to the 6-pin (2x3) ISP programmer port. It is not possible to do ISP programming through the 6-pin (1x6) serial port.

If eeprom data or code corruption really is the cause, then you should be able to rescue it with the bitbang ISP method. (It's not the most straightforward procedure, but it sounds you have a high level of competence.) It will require a custom cable, or at least several jumper wires soldered into the ISP header location, with the other end stripped and inserted into the USB-TTL cable end.

The following pages discuss the software and hardware setup needed to perform this programming:

"Intro version:"
http://itpedia.nyu.edu/wiki/Bootloading_the_Arduino--Using_Only_the_Arduino!

"Software hints at..."
http://www.geocities.co.jp/arduino_diecimila/bootloader/index_en.html

"Hints about wiring up the cable"
http://exmrclean.blogspot.com/2009/05/burning-avr-boot-loader-with-usb-ttl.html


If this is more work than you're interested to perform, we would be willing to take a look at it here, and see if we can diagnose the problem. If so, please contact us about this through the web store: http://evilmadscience.com/contact


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: preiner (offline) on Monday, January 10 2011 @ 12:29 PM PST  
preiner

Clarifications enclosed:

1) AVR Pin 1 is high. Sorry i said PIC

2) I dug out freq counter and it is measuring 16MHz, so I can eliminate the clock

3) I DO HAVE the cronodot option. I was setting the date/time with it, when the clock bricked.

I then removed the DOT to debug. I have not reinstalled it yet.

4) I did try resetting with +/- held down and power cycling. I also tried + & Z, neither seemed to work.


PROGRAMMING Qs:

I plugged the PROVIDED USB cable into the 6 pin flat header. I presume that is the port for programming the AVR AND burning the bootloader. But MAYBE Im wrong. According to the comment, I need to hack the cable into J3 (requires scrounging a small header).

Is this correct? If so, whats J2 header for? Is this port somehow limited?

Sorry for dumb questions, Im totally new to AVR, but all of the concepts are very straight forward.

I just need a nudge to get this unit running again.

Im sure its something dumb.



Forum Apprentice
Apprentice

Status: offline

Registered: 01/10/11
Posts: 6

Profile Email    
   
By: Windell (offline) on Monday, January 10 2011 @ 12:48 PM PST  
Windell

I plugged the PROVIDED USB cable into the 6 pin flat header. I presume that is the port for programming the AVR AND burning the bootloader.


That cable and port are for standard "Arduino" programming, they are not actually capable of altering the bootloader. Normally this is a *good* thing, because most people don't actually want to alter the bootloader, and it is possible to (more or less) permanently brick the AVR with the ISP programmer, if you are careless.

It should not be possible to corrupt the memory without an ISP programmer. However, we have actually had very rare reports of apparently random, isolated cases where the Bulbdial seems to have some sort of unprovoked firmware corruption. Your case sounds like this, after the list of things that you've tried. We have not been able to reproduce anything like this here, and again, it has been seen only been several times cases amongst a great many kits. In those few cases, it seems to be permanently fixed by rewriting the firmware once.

There may be something in the bulbdial clock design that is contributing to these failures, but if so, we have not yet been able to identify it.

>Im sure its something dumb.

No reason to assume that; if this is the same problem (and not just a flaky solder joint somewhere), then the solution is actually non-obvious.


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: preiner (offline) on Monday, January 10 2011 @ 04:09 PM PST  
preiner

I bought a 6 pin dual header, so I can (in theory) build a cable to redo the bootloader if needed.

However, I am loathe to do so at this time.

Can I reprogram the firmware from the standard 6 pin flat header that is included?

Currently, when I try, I get sync errors. I have no idea how to debug this.

So, could you please verify the following?

1) black pin of the provided USB cable goes to the the pin closest to the bottom edge (i believe its pin 1 as it has a square solder pad

2) It should be set to 9600 baud, no parity, no flow control

3) Power should be OFF (no applied) when I attempt to burn (seems wierd)... I do NOT have the USB power jumper option enabled

4) This is Diecimila board with ATmega168

5) Is there any pin or anything that will pulse at boot up to indicate bootloader working?

I.E. Could I put a DVM on pin X and at completion of boot, it would pulse slow enough to see on a DVM?


6) IF I have one of the rare firmware corruption issues, then the following procedure would restore it...

a) UNPLUG board
b) Connect USB to provided to J2
c) Launch Arduino 17
d) Set serial port to COM x (as approp)
e) Set board to Dicemila with ATmega168
d) Open Beardy2
e) Verify succesfully
f) Upload with no errors
g) Unplug USB
h) Power on board






Forum Apprentice
Apprentice

Status: offline

Registered: 01/10/11
Posts: 6

Profile Email    
   
By: Windell (offline) on Monday, January 10 2011 @ 04:48 PM PST  
Windell

>However, I am loathe to do so at this time.

Again, if this doesn't sound like something you want to do *and* you're pretty sure that it's not a solder joint that opened up *and* it's not responding to normal serial programming, you might want to consider sending the board to us to see if we can find anything wrong with it.

>Can I reprogram the firmware from the standard 6 pin flat header that is included?

If you mean "all of the firmware including the bootloader," then *probably.* It might be possible to add some temporary wiring from those pins to the 6-pin ISP to reprogram it that way-- I can look into it --but you'll still need to do the software setup to enable bitbang-mode programming.

If you mean "just the firmware that sits on top of the bootloader," then, yes, *if* the firmware hasn't actually been corrupted. If it has been corrupted, it's likely that the bootloader (which is part of the firmware) is also corrupted-- which is why I brought up the ISP programming.


>Currently, when I try, I get sync errors. I have no idea how to debug this.

You haven't said, but I presume from what else you've written that you are trying ("when I try" ) to write the firmware through the USB-TTL cable, using the standard "bootloader" method. It could be that the clock is not getting power, or that the programming setup is wrong somehow, or that the firmware is corrupted.


>1) black pin of the provided USB cable goes to the the pin closest to the
>bottom edge (i believe its pin 1 as it has a square solder pad

Yes, as shown on p. 66 of the instructions.

> It should be set to 9600 baud, no parity, no flow control

I'm not sure what you're doing here. There *should not* be any option for you to set the programming baud rate, unless you go in by hand to edit the boards.txt file. (And you probably shouldn't do that, except to add new definitions.) If you *did* go into boards.txt and edit the baud rate to 9600, that will ensure that it no longer works for serial programming.

>Power should be OFF (no applied) when I attempt to burn (seems wierd)...
> I do NOT have the USB power jumper option enabled

If you are trying to write the firmware, using the USB-TTL cable in the normal position, and you do not have the USB power jumper in place, then you *do* need to have the clock externally powered, preferably with its normal power supply.

> This is Diecimila board with ATmega168

That's what you should tell the Arduino program, anyway. Wink

>Is there any pin or anything that will pulse at boot up to indicate bootloader working?

No, I don't believe so. The normal sign of ending bootloader phase is starting the main program, i.e., turning on the clock. There's also some serial communication software in there that you could use to set the time, if it were running the main program.


6) IF I have one of the rare firmware corruption issues, then the following procedure would restore it...

a) UNPLUG board
b) Connect USB to provided to J2
c) Launch Arduino 17
d) Set serial port to COM x (as approp)
e) Set board to Dicemila with ATmega168
d) Open Beardy2
e) Verify succesfully
f) Upload with no errors
g) Unplug USB
h) Power on board

First, the board *does* need to be powered on for programming. Second, this procedure will only rewrite the "bulbdial" firmware-- the part that sits on top of the bootloader. If the corruption is in the bootloader, you won't be able to upload the replacement firmware.



Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: preiner (offline) on Monday, January 10 2011 @ 06:51 PM PST  
preiner

I didnt edit any ini or conf files.

I simply asked because I enabled verbose upload debugging. When upload starts, the UI spawns avrdude to do the actual upload. That said it was overriding the serial port settings and setting the baud rate to 19.2 K instead of the default 115K.

I wasnt sure if that was appropriate for this board, so I thought I might have missed a configuration step somewhere. Based on your response, apparently not.

After several attempts at uploading the beady2 sketch without any success, Im leaning towards the boot code being corrupted being the culprit.

As I understand it, the bootloader needs to be functional for sketches to be downloaded through J2. Otherwise I have to use the ISP connector.

I found a header lying around that fits the ISP holes, but I dont know if the board uses custom bootloader code or if it came from the manufacturer with code preloaded, and if so which version.

Plus I have to hack a cable together, which maybe too much hassle.

Im going to look at the soldering again tonight, but if I cant find it. Ill contact you

Since pwr, gnd, reset, and osc are all working, Im trying to think of a failure mode that explains the symptoms so I know where to focus my attention.



Forum Apprentice
Apprentice

Status: offline

Registered: 01/10/11
Posts: 6

Profile Email    
   
By: Windell (offline) on Monday, January 10 2011 @ 07:40 PM PST  
Windell

I simply asked because I enabled verbose upload debugging. When upload starts, the UI spawns avrdude to do the actual upload. That said it was overriding the serial port settings and setting the baud rate to 19.2 K instead of the default 115K.

I understand now. I believe that 19.2 k is actually the correct default for the Arduino with '168.

I found a header lying around that fits the ISP holes, but I dont know if the board uses custom bootloader code or if it came from the manufacturer with code preloaded, and if so which version.

We use the stock Arduino bootloader, which is what you get when you select "Burn bootloader..." from the Arduino menu, or by following the directions in the links that I gave earlier. After the bootloader is loaded, we use the USB-TTL cable to upload the bulbdial firmware program.


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Anonymous: macegr () on Tuesday, January 11 2011 @ 01:00 AM PST  
Anonymous: macegr

Windell...what are the fuse settings for the Bulbdial? Specifically brownout? I had some fun experiences with random firmware corruption on the ATMega with low brownout voltages. Shouldn't be as much of a problem at 16MHz, but one of the "gotchas" on the Arduino site is how they tell you the fuses are set to no BOD, yet the actual shipped Arduino boards have a 2.7V BOD. If you have a nice smooth power supply I might go as aggressive as 4.3V...it's what I had to do at 20MHz for sure.





       
   
By: Windell (offline) on Tuesday, January 11 2011 @ 05:15 AM PST  
Windell

The fuse settings that go with Arduino 0022, for the diecimila w/ '168, are:

diecimila.bootloader.low_fuses=0xff
diecimila.bootloader.high_fuses=0xdd
diecimila.bootloader.extended_fuses=0x00

And, that's what we normally burn; it gives a brown-out voltage of 2.7 V. We've been trying to stick with the "official" configuration, but perhaps moving away, to 4.3 V would reduce the possibility of EEPROM corruption. (In either case, if it is power dropouts (while writing flash) that are the root issue, then the BOD is not presently doing its job.)

Now, looking at the fuses that we programmed, I do actually see a problem here. It looks like *this particular chip* (which was not programmed in our normal workflow) was probably burned with: 0xff, 0xda, 0x05 -- the values from the '328. That gives BOD of 4.3 V (which should be okay, as above), but also gives the wrong size bootloader section. The latter is a serious goof on our part. It means that it the chip cannot be programmed through the bootloader-- the bootloader will need to be reflashed to work properly.

preiner, I'd definitely suggest that you sent the board back to us for reprogramming. While the bootloader problem is probably not the cause of the initial corruption, it is definitely something that should be fixed one way or the other, so that the clock gets back to its original functionality.


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: preiner (offline) on Tuesday, January 11 2011 @ 07:07 PM PST  
preiner

After reading about BitBlaster mode, I realized this isnt all that hard. I wired up the ISP cable and using AVRDUDE-GUI, was able to successfully talk to the chip.. You are correct that the fuze info was wrong (was set for the 328). I was able to change it and verify the change. Actually super easy in this UI. I also cleared, rewrote, and verified the boot loader using ATmegaBOOT_168_diecimila.hex from Arduino 22 AFTER running a verify pass indicated that the bootloader DID NOT MATCH That also worked perfectly. But I cant load beady 2 from the regular serial port. So my questions are: 1) Is this the correct bootloader? 2) Can I upload Beardy 2 directly using BITBlaster mode? 3) Whats the different between a .eep file (that AVRDUDE-GUI wants) and a .hex file which Arduino produces when compliing> 4) My board reports unlock code of 3F? That seems correct but I will ask anyway PS. This is incredibly fun.


Forum Apprentice
Apprentice

Status: offline

Registered: 01/10/11
Posts: 6

Profile Email    
   
By: preiner (offline) on Tuesday, January 11 2011 @ 07:46 PM PST  
preiner

Big Grin Hurray! It works fine again... After actually reading about the AVR architecture for 10 mins, I realized my previous questions were a bit absurd. I used avrdude-gui to write the beardy2.cpp.hex file to the flash area and I erased the eeprom. Voila! It is actually REALLY easy to fix a bricked chip. All you need is the small ISP header, a cable, AVRDUDE-GUI (with ser-jtag), and the hex file. Happy Days...


Forum Apprentice
Apprentice


Status: offline

Registered: 01/10/11
Posts: 6

Profile Email    
   



 All times are PDT. The time is now 01:59 PM.
Normal Topic Normal Topic
Locked Topic Locked Topic
Sticky Topic Sticky Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Able to Post 
Filtered HTML Allowed 
Censored Content 

Evil Mad Scientist Forum Archives — Read only!

Please visit our new forums for new discussions.


DIY Hardware for Electronic Art


The Original Egg-Bot Kit


Octolively
Interactive LED kits


Meggy Jr RGB
LED matrix game
development kit.


Business-card sized
AVR target boards


Peggy 2
LED Pegboard kits

My Account






Lost your password?