While developing an alternative firmware for the Ice Tube Clock, I have used the ISP header on many occasions, but not always with good results. Sometimes the clock stubbornly refuses to be programmed. Sometimes my USBtinyISP programmer throws a tantrum and refuses to program anything until disconnected and left alone for a while. I would guess this is why Adafruit does not guarantee that the clock can be programmed in-system: "We dont [sic] guarantee that you can program the clock in-circuit [...]"
Adafruit does suggest removing the side PCB, which greatly increases the chances of successfully programming the clock. I have also noticed that reducing display brightness to the minimum level before programming also seems to help. So the problem has something to do with driving the VFD display.
My favorite trick is to force the clock into sleep mode by jumpering both ends of R2 (pictured below). Although attaching the jumper is a bit inconvenient, doing so completely disables the display. Since I started using this method, my clock has never refused programming and my USBtinyISP has been well-behaved.
Ice Tube Clock Programming Tricks
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- russell 27
- Posts: 242
- Joined: Thu Sep 12, 2013 3:59 pm
Re: Ice Tube Clock Programming Tricks
I always take my CV1220 battery out, seems to do the trick.
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Ice Tube Clock Programming Tricks
Do you have any ideas on why removing the battery improves programming reliability? I believe you, I'm just trying to understand out why that helps.
- russell 27
- Posts: 242
- Joined: Thu Sep 12, 2013 3:59 pm
Re: Ice Tube Clock Programming Tricks
I think you know way more about AVRs than I do. When I locked that 328P my fascination and interest grew ten fold. I can't say this is what's going on, but the SPI pins, MOSI (pin 17), and SCK (pin 19) are used not only for their programming role, but for another part of the circuit, driving the MAX chip. Don't know that any battery voltage or noise is bleeding back from there, but I read, sometimes another functional connection to the circuit from these pins can cause a problem. I set up my USBTINY on a circuit board, to either plug into a ZIF socket directly (isolated), via header pins, or of course directly into ICE TUBE header. I have never had a problem with the ZIF header connection, locking or anything. Never had a problem programming though the Ice Tube header either, but I always have the battery out. Before the Ice Tube I never programmed ISP, so I had wondered how much the actual circuitry affects programming. Resistors were recommended to isolate.
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Ice Tube Clock Programming Tricks
I also suspect that the connections to the MAX chip are the issue. Jumpering R2 forces the clock into sleep mode, and when the clock sleeps, all power (both system and boost voltage) to the MAX chip is turned off. I think that prevents the MAX chip from confusing the microcontroller and/or ISP programmer. But why on earth do the MAX chip digital inputs have any effect? That's still a mystery to me.Russell 27 wrote:Don't know that any battery voltage or noise is bleeding back from there, but I read, sometimes another functional connection to the circuit from these pins can cause a problem.
I suspect that it has something to do with the rather large (~1 volt) ripple in the boost supply somehow feeding back through the MAX chip inputs. I infer that because reducing display brightness to the minimum and removing the IV-18 tube both reduce that ripple. Since I now have access to an oscilloscope, I should test this theory sometime...
I know of other Ice Tube Clock hackers who do essentially the same thing, but with an AVR development board... usually an Arduino Uno, but I prefer the Barebones AVR dev. board. That method seems to be extremely reliable.Russell 27 wrote:I set up my USBTINY on a circuit board, to either plug into a ZIF socket directly (isolated), via header pins, or of course directly into ICE TUBE header. I have never had a problem with the ZIF header connection, locking or anything.
- russell 27
- Posts: 242
- Joined: Thu Sep 12, 2013 3:59 pm
Re: Ice Tube Clock Programming Tricks
In battery back up aren't all driver outputs shut off anyway, once pin 13 reads less than 1.1 volts from divider?
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Ice Tube Clock Programming Tricks
Yes, so I believe you can also remove the power jumper from the USBtinyISP and program the chip on the battery. I think that would only be reliable as long as the backup battery is good.Russell 27 wrote:In battery back up aren't all driver outputs shut off anyway, once pin 13 reads less than 1.1 volts from divider?
I jumper R2, so I can program the clock using the +5v from the USBtinyISP with power jumper installed. The jumper pulls the voltage on pin 13 to ground, forcing the clock into sleep (battery backup mode).
- russell 27
- Posts: 242
- Joined: Thu Sep 12, 2013 3:59 pm
Re: Ice Tube Clock Programming Tricks
That's where I get lost. If the clock outputs are already off (asleep), then why do you need to force it?
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Ice Tube Clock Programming Tricks
With the power jumper installed on the USBtinyISP, the programmer will supply +5v, so the output from the voltage divider will rise above 1.1 volts. With the USBtinyISP power jumper removed and the clock plugged into the wall, the output from the voltage divider will be above 1.1 volts, because the voltage regulator+D2 supplies ~4.8 volts. So the clock will not be asleep when the programmer is attached--unless the clock is only powered by the battery backup. But relying on the battery voltage for programming may also be unreliable with an old battery.Russell 27 wrote:That's where I get lost. If the clock outputs are already off (asleep), then why do you need to force it?
- russell 27
- Posts: 242
- Joined: Thu Sep 12, 2013 3:59 pm
Re: Ice Tube Clock Programming Tricks
Okay, for some reason I thought that you isolated that in your battery hack, my bad there, stupid moment. I'd say that the chip is getting mixed signals on the ISP, when the chip is powered. Don't know why I don't have any problems, battery wouldn't seem to make any difference. I thought the resistors used in the circuit image might help give authority to the ISP.
Last edited by russell 27 on Sun Nov 10, 2013 10:21 am, edited 2 times in total.
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Ice Tube Clock Programming Tricks
Oh, yes, you are correct in regard to clocks with the battery hack. I was thinking in the context of an unmodified Adafruit Ice Tube Clock. But even with the battery hack wiring, some programmers expect to sense the target voltage through the ISP's VCC pin. So the clock must be powered to be programmed, and when using the AC adapter, jumpering R2 is still necessary. That is the reason my xmas-icetube redesign has a programming jumper even though it uses the extended battery hack.Russell 27 wrote:Okay, for some reason I thought that you isolated that in your battery hack.
- phild13
- Posts: 247
- Joined: Mon Sep 10, 2012 1:05 pm
Re: Ice Tube Clock Programming Tricks
Interesting.
When I programmed the first chip in the clock (adafruit kit supplied boards), I just pulled the tube out, the battery out, stuck the new blank 328 chip in, connected the usbtinyisp (without the jumper installed on the programmer) to the board, powered the clock with the 9v power adapter and told avrdude to make inatall-fuse, make install. So either I was lucky, or the programming gods were kind to me.
I have since made a programmer board with a zif socket to program the chips so I won't have any issues, but if one is going to program the chip on the clock I would recommend that Johns advice be followed just to be safe.
When I programmed the first chip in the clock (adafruit kit supplied boards), I just pulled the tube out, the battery out, stuck the new blank 328 chip in, connected the usbtinyisp (without the jumper installed on the programmer) to the board, powered the clock with the 9v power adapter and told avrdude to make inatall-fuse, make install. So either I was lucky, or the programming gods were kind to me.
I have since made a programmer board with a zif socket to program the chips so I won't have any issues, but if one is going to program the chip on the clock I would recommend that Johns advice be followed just to be safe.
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Ice Tube Clock Programming Tricks
I'm just estimating, but that strategy worked for me more than 90% of the time... and probably more than 95% of the time. The unreliability isn't a huge deal... until you start writing your own firmware or firmware mods, and want to program ~20 times in a row to test different things.PhilD13 wrote:When I programmed the first chip in the clock (adafruit kit supplied boards), I just pulled the tube out, the battery out, stuck the new blank 328 chip in, connected the usbtinyisp (without the jumper installed on the programmer) to the board, powered the clock with the 9v power adapter and told avrdude to make inatall-fuse, make install.
For me, it was really frustrating when I had almost gotten a bit of code to work just right, and the programmer started throwing a tantrum and consistently refused to allow programming. I suppose it could have also been the clock or my USB driver throwing the tantrum, but leaving my Adafruit USBtinyISP on a shelf for a day always fixed the problem.
Thankfully, ever since I discovered the jumpering-R2-trick, I haven't had to deal with tantrums or, much less frequently, mysteriously bricked chips.
- russell 27
- Posts: 242
- Joined: Thu Sep 12, 2013 3:59 pm
Re: Ice Tube Clock Programming Tricks
To clarify the matter, the first chips I programmed were PICs. I always programmed from the DEV. board, never had used ICSP. When I put the ICE TUBE together and programmed my first AVR, I set up the USBTINY to program the Atmega the same way, out of circuit, mainly because of familiarity. Eventually I figured, might as well try ISP, headers there. I was a little weary, conflicting voltages can be a problem sometimes, and I didn't really know to what extent or when the circuit could be a factor in affecting programming ability. So I always unplugged the power supply, and removed the battery just to be on the safe side. John pointed out something that I had over looked, USBTINY programmer is powering the entire circuit, the Atmega is running the program as it would from the power supply, sans the tube. He was already way ahead of me in the solution. I don't know why I didn't have any problems programming. One thing is I always did so manually, telling AVRDUDE exactly what to do, haven't tried make file command yet, could that make a difference? Companies use ISP programming all the time, so there must be some kind of determination in where the circuit itself becomes a problem, and what's needed to program successfully. The circuit I posted above is an example of a technique I had seen.
- phild13
- Posts: 247
- Joined: Mon Sep 10, 2012 1:05 pm
Re: Ice Tube Clock Programming Tricks
If I program a chip in circuit then I always power the device with it's own power unless the developer specifically states not to. I also always remove the battery backup if there is one. I do not have the usbtinyisp supply power to the device being programmed in circuit.
The usbtinyisp is a low power usb device. This limits the current available to the usbtinyisp to one unit which is 100mA and the usbtinyisp uses some of this power. I always thought that having the usbtinyisp supply power to a circuit like the icetube clock was a bit risky due to limited current that is available (your powering both the usbtinyisp and the clocks 5 volt circuit) and that could result in random failure.
If I program a chip out of circuit, then I have the USBtinyisp supply the power.
The usbtinyisp throwing a tantrum could be a symptom of pulling to much power. I had this happen when accidentally powering an arduino and breadboard through the usbtinyisp.
The usbtinyisp is a low power usb device. This limits the current available to the usbtinyisp to one unit which is 100mA and the usbtinyisp uses some of this power. I always thought that having the usbtinyisp supply power to a circuit like the icetube clock was a bit risky due to limited current that is available (your powering both the usbtinyisp and the clocks 5 volt circuit) and that could result in random failure.
If I program a chip out of circuit, then I have the USBtinyisp supply the power.
The usbtinyisp throwing a tantrum could be a symptom of pulling to much power. I had this happen when accidentally powering an arduino and breadboard through the usbtinyisp.
Please be positive and constructive with your questions and comments.