Glitches Explained

Turned out it was the "noise" (in this case, deterministic unwanted patterns on some key voltages) in the noisy testmode in which there was a lot of switching going on. Thing of my chip as a spider on a thin web - the thin web is the supply and ground connections. Now, the spider has a fan that's out of control - and that keeps bouncing it all around by blowing air around uncontrollably. The solution, in this case, increase the moment of inertia of the spider by increasing it's mass - here, add bypass caps between supply and ground. Electrically, what you're doing to help out the spider is putting a sink that'll make the air the fan is blowing recirculate back to itself - so there can't be any uncontrollable bouncing. Clear analogy ja?:)

Interestingly enough - on the node where the noisy switching signal was being muxed out - if I connected a long cable, I could make things more noisy - and get the glitches back. The extra current pulled from the supply in transient to work the capacitance of this cable was enough.

Glitches Galore

Damn! The thrill of getting something done evaporates when you see that it works most of the time, but there are cases when it doesn't. Tricky glitches screw you up one in 5 times and that's enough to make it look like crap. When it's all digital (or supposed to be) you expect stuff to work 100% of the time. Take this example. My chip takes a pulse to increment the register pointer. We use a board with push-buttons to generate these pulses. To go from state 0 to state 15, you hit the button 15 times. With software, it's trivial to write a function that takes an argument and goes to a specified state in a jiffy. Problem is, there are times it's off by 1 state - it sometimes rolls over into state 16. You get a feel for the mountain of work involved in testing something before you can sell it. Nothing like having many hands here to make work light. Eyeballs too of course - it's the information age.

In this case, it's looking like the assumption of 100% digital is incorrect. One of the states sends a rather noisy signal to one of the pins and that might mess up my setup that has lots of parasitic inductance in the leads - rather than transmission lines to convey the signals cleanly. Probably a signal integrity thing here. Never had to deal with that before.

Maker Makes It

An end to end solution. That was fun - developing the software and hardware and delivering a complete solution - giving a demo. All in a day's work. Here you see the Arduino mating with a custom board delivered by ExpressPCB.com and assembled by me with parts from Digi-Key. Systems, here we come!



Of course, this is not the end. It's something I can use, but not something everyone can depend on, without doling out more TLC than they care to. Packaging is required - we need headers on the custom board to mate it with the Duemilanove with minimal effort. Plug and play is the name of the game. Anyone know how to launch a program on Win or Unix automatically when you plug something into USB? How does the PC know what you plugged in and what to launch? Good q.

Sub-Microsecond Delays with Arduino

It's possible!

The Arduino delayMicroseconds() function creates the shortest delay possible from within the Arduino language. The shortest delay possible is about 2 us (microseconds). Not true - I've tried and the shortest is about 4.5 us.

For shorter delays use assembly language call 'nop' (no operation). Each 'nop' statement executes in one machine cycle (at 16 MHz) yielding a 62.5 ns (nanosecond) delay.

__asm__("nop\n\t");

__asm__("nop\n\t""nop\n\t""nop\n\t""nop\n\t"); \\ gang them up like this

Really, why not a loop?

Dat's vy :

If you write a C loop, it will change into NOP instructions and compares/increments for counters. So your timing will be off. Unrolling loops is a standard practice to get rid of the compares/increments.

Verdict :

You also need to know stuff on this page :

http://arduino.cc/en/Reference/PortManipulation

If you use digitalWrite(), a single write takes 4.5 us to execute. But using

PORTB = PORTB & B11101111;
to set pin 12 low, with no intentional delay, I see a delay of about 400 ns. So much for being able to get 62.5 ns! If I put in 4 NOPs, I get the delay increasing to 620 ns. So we're on!

Space Left on Your Board - What to Tack On

Put some 0603 or 0805 land connected to some large pads that you can solder wires to. Same with some SOT23's since you can connect decent robust transistors to those. Then, you're all set to blue wire your board and cover up your mistakes.

National Trips Up TI

LM2611 needs a min of 2.7V, didn't want that to limit the min VDD at which I could talk to my part, so I run if off my 6.6V rail that the TPS61085 is putting out. Not sure where my big mistake is, but the joy of getting the 61085 working after realizing that NXP puts stripes on the CATHODE of its Schottky diodes unlike the rest of the world soon evaporated when I saw what the LM2611 was doing to the boost output. That's a big lesson - you need to think about high current issues - a charge pump is probably way better off here in terms of working right off - especially when you've got a fixed voltage rail. What was I thinking? I thought - hey, a Qpump needs a regulated input, I'm better off with a switcher. What I didn't tell National in their feedback form was that the Cuk is pulling about 1A out of the boost. The table is getting hot!

I am using the LM2611A driven by an on-board boost (TPS61085) to realize a -5V voltage. I am using components according to the datasheet Figure 1. The boost output is correct when the LM2611 is disabled - it is 6.6V solid. However, when the LM2611 is enabled, there is large ripple on the boost output and the feedback node voltage of the LM is about 0.4V and the output is about 2V. The boost output average value is still 6.6V when the boost is overcompensated - with a 0 ohm and 1 uF cap on COMP. With 51k and 1 nF, the ripple is about 10V p2p. There is no other load on either the boost of the Cuk. Any help I can get in resolving this issue will be greatly appreciated.

Looking at the LM2611 datasheet - it looks like the startup current (despite what is claimed as soft-start) is way up there in the 1.5A range. So it could be that the 61085 is cycling in and out of UVLO all the time. So nothing really works. I wonder if a charge pump would really be better of here - if you can find a low current part, go with it.

Their response :
__________________

The issue is you have a boost regulator (TPS61085) is driving a dynamic load (the LM2611). So first you should probably put a filter between them - for example a cap to further reduce any existing ripple from the boost regulator. The other thing to check is the inductor you've selected for the boost regulator. Depending on the current load of the LM2611, it will also determine the value of inductor of the TPS61085. Also, you probably should first check the LM2611A circuit by itself, with a test bench power supply, and then you can see thecurrent levels you can expect (both average current and the transients). From then you can optimize the boost regulator circuit inductor and other parts (output cap, etc) appropriately.
_____________________

What they missed (failing to see things from the customer's point of view can sometimes be fatal. But, a big outfit like NSM is probably safe) :

1) I've done my layout already. If they know something like this probably won't work, why not specify the source better on their datasheet?

2) Who really has the luxury of trying out different caps and inductors? That's nuts - this is not like running spice on your ckt.

My mistake was in not using jumpers to isolate the different modules and allowing test-sources (clean, expensive) for verifying the modules. What I did try was to force the 6.6V output of the TI boost and see if that helped - but I was forcing through a really long cable, so it probably had almost no effect.

Any, end of the story is that most of the bench triple supplies have a negative supply that you mostly can't use for anything else, so all I had to do - and here, my great idea of putting down some non-standard pads at the last minute really helped me out - I was able to put down a 2N7002, a resistor and some wires do give the MCU more control. Stuff works pretty well actually.

Maker Breaks It

Not only did my on-board boost not work (TPS61085), but the current it pulled from the supply was so weird in transient that it was the least I could do to 1) Turn off power, 2) Take that chip out. I saw straightaway some mistakes I had made in my design and approach :

1) I had left the FREQ pin floating. Wonder how you catch stuff like that without an LVS?
2) I didn't put in a jumper on the supply to the boost - I should have made it easy to cut this thing out - as it turned out I had to use the heat stream to get the chip off and there were still problems after that.
3) Shame on me - knowing about the backgate diode and having PMOS pullups, I didn't put in a jumper to cut the PMOS pullup out - now that backgate diode is clamping on of my comm pins - but, somehow, though the scope doesn't pick it up, the interface still works.
4) I should have put a jumper cutting the inverting boost off from the output of the boost. Childishly simple, but it's amazing what you can not-think of when you're under pressure. Lesson - think modular.
5) I should have put more pads on the board to let me solder some wires to drive these functions from the outside in the event they didn't work. Lesson - think modular and what-if!
6) In soldering (assembly), I should have thought modular too - start off with the boost and see if it's working.

Weird, with an input supply of 3.5, and the chip removed, and supply passing through the boost inductor (3 uH) and then going into the Schottky, the other side of the Schottky diode was 0.45V. Wha?

Also, the value for the FB node advertised on the TPS61085 datasheet is 1.24V, I was seeing a 0.6V that scaled with supply. What's going on?

Atleast I didn't get 2A of current when I turned on the supply:)

Otherwise, the interface works - the Maker has landed - in one week, a GUI running on a PC with it's own serial interface code, talking to the MCU and getting ACKs, MCU commanding the chip in test-mode. Not bad. I feels good.

Arrays in AHK

To learn how to work with arrays in AHK, read

1) Help docs for StringSplit (tells you the convention - there's nothing set in stone, but you want to let var0 have the number of elements and var1,..,varN have the actual data

2) This great post from meister Infogulch : [lib] pgArray - A solution for Manipulating AHK's Arrays v2

3) Look at the help on Arrays - you can search the Index for that.

To create a string from an array, you're looking at something really nasty like

string =
Loop %var0%
{
string .= var%A_Index%
}

I know, you wish perl was easier to use on Windows, you with AHK was more like perl. But, what can you expect for $0.0? It's a great tool for the price.

Hello World Arduino GUI

Status :

Basic GUI in AHK to talk to MCU - done
String manipulation to give user visual feedback on chip state - pending

Biggest headache was talking to the serial port in Windows. Sure, there are 1000's of GUI programs out there, but what happens when you want to write a program where you can push a button and get data out? Now you need a lite solution. Luckily, the dons on the AHK forum have cooked something up that calls the buildComDCB DLL from M$. It's not a 'lite' solution, but...

Now I'm faced with a quandary - how do I process data - it was a snap in Perl, but AHK's emphasis is not on data manipulation, so it doesn't give you 'lite' methods :(

Leave Well Alone

I had given up on my USB/serial at home after my outfit's MCU dev board and the MSP430 failed to be installed properly. Learnt later that both used direct USB and I was always pointing windows to the virtual COM port drivers. I try half heartedly to plug in my Arduino today and - pleasant happenings - it works without me having to do a thing. There are some things you have to give M$ credit for. BTW, writing to the COM port from Autohotkey or anywhere (including MS-DOS command prompt) is the last link in my chain. There seems to be a ray of hope thanks to this post which I intend to scrutinize minutely :

Seial (COM) Port Console Script

Arduino Trumps All

Gave up on my own outfit's microcontroller after the code they have on the website failed to compile on their own assembler. Tough one. Arduino is super easy to use. Great job by the azzuri on this one. The IAR rep who called me to follow up on my download of the kickstart version was also amazed.

One disappointment was that, despite running off a 16 MHz clock, the Arduino cannot put out a pulse narrower than 4 us on one of its output ports. Might need something fancier than digitalWrite to accomplish that.