I knew I was right!

My son recently got his GCSE results – all ‘A’s and ‘A*’s.  He outshone my 7 ‘A’s, 2 ‘B’s and a ‘C’ (in Art) that I achieved in my ‘O’ Levels and I’m really proud of him.  It got me to thinking about my Electronics ‘AO’ level.

I got an ‘A’ (there were no ‘A*’s in those days) but it always bugged me that my practical project, a speech synthesiser based on the SP0256 speech chip from General Instruments (now Microchip) never worked.  I blamed the PCB.  It wasn’t a bad first attempt at etching but I had to repair some of the thinner tracks and eventually ran out of time.

After I got my Arduino Uno, I looked around for some projects and came across this gem at http://nsd.dyndns.org/speech/.  I still had an SP0256 chip from the 1980’s and a 3.2768MHz crystal, so I set it up on the breadboard and, lo and behold, it worked!

So I was vindicated – it was the PCB at fault, not my software coding.

I went on to design a dedicated circuit on stripboard with an ATmega328P (the processor on the Arduino Uno) and a serial interface, so I could upload code from the Arduino IDE using an USB to Serial converter.  Here are some pictures if you are interested:

What’s your favourite part?

Every engineer has a favourite part.  Every so often, an IC comes along that is so useful, you wonder what you did before it came along.  You use it wherever you can and you use it everywhere.

There are some great examples: The ubiquitous 555 timer; the 741 op-amp; and so on.  Of course, you use the 7555 CMOS version because it is lower power and doesn’t have any power supply crowbar problem and the NE5532 low noise amplifier, but basic topology is the same.

With power supply components, the LM317 adjustable linear regulator springs to mind.  But what about switching power supplies?  Pretty much every switching regulator is proprietary, so it’s a little more difficult.

Well, my favourite part is the PI3749 ZVS Buck-Boost regulator.  With an input voltage range of 16 to 34V and output range of 12 to 28V, the Buck-Boost architecture means the output can be either above or below the output voltage.  The output voltage is adjusted by feeding back a portion of the desired output through a voltage divider to the error amplifier’s input.

There are a couple of ways of doing this.  One is to use a digital potentiometer.  The top resistor in the feedback chain is the one that needs to be changed, so the digi-pot needs to be able to support almost the entire output voltage.  Most are designed for 5V supplies but there are some high-voltage ones from Microchip that fit the bill: The MCP45HVxx I2C version and MCP41HVxx SPI version.

An alternative, one that is implemented on the evaluation board, is to have fixed resistors for R1 and R2 to set the nominal trim and then to add a third resistor to the error amplifier node.  Kirchhoff’s Current Law stated simply says that all currents flowing into a node must sum to zero.  So, by using a DAC to apply a voltage to the other end of this resistor, we can add current to or subcontract current from the error amplifier node, trimming the output voltage.

The other great thing about this part is that the output can be set up to provide constant current.  An on-board differential amplifier with a level shifted, SGND referenced output is used to sense current on high voltage rails, implementing a current control loop outside the voltage loop.  This is ideal for battery charging or for driving LED strings.

There are so many applications for this part in the industrial market that it has quickly become my favourite switching regulator.

What’s your favourite and why?

Will it meet EMI?

In my previous post I mentioned Electro-Magnetic Interference. This got me thinking about the topic itself.

One of the things I was most worried about when I started my job as Field Applications Engineer for power components was how to help customers who phoned up from the EMI test lab where the equipment was failing the limits.  Let me give you an example.

I received an e-mail from an establishment that was testing a piece of equipment.  It was failing conducted EMI and they sent me the frequency plots to prove it.  “Probably a layout issue, ” I mused in reply and asked them to send me the layout for review.

Now, as it turned out, this establishment wasn’t the manufacturer of the equipment and a few days later, I received a slightly embarrassing phone call from the manufacturer telling me I told their end customer that their layout was terrible.  They actually took it in good humour and invited me down to review the layout with their engineers and PCB designers, an offer I eagerly accepted.

Well, it was me in a room with the design engineer, the PCB layout engineer, the project manager, the production manager and the MD of the company, all looking to me for answers.  I loosened my necktie, rolled up my sleeves and got to work.

Well, on reviewing their layout, there were no big mistakes.  They hadn’t filled a plane under the filter module, so the switching frequency of the converters wasn’t getting past the filter by capacitive coupling.  It all looked rather well done actually.

The fact remained though that the switching noise from our converter was getting out of the box somehow.

I felt somewhat deflated (because I couldn’t help them rather than because I had been proved wrong in my assertion that it was a layout issue) but promised to write up the one or two minor tweaks that could be done in a report and added that some cooper shielding around the regulators may help reduce the noise.

Almost as an afterthought, they asked me whether I would like to see the unit and I graciously accepted (more because I love electronics than anything else) and I’m glad I did!  I spotted that they had a cable that ran from the one side of the enclosure, all the way to the other where the inlet connectors were and guess what, it passed right over the top of our switching regulator.

The smoking gun I had been looking for!

I suggested re-routing the cable, away from the regulator and as far as I can tell, this has solved the problem and the device is now passing its EMI tests very well.

The moral of the story is that in all my years as an FAE there has never been an EMI problem that cannot be solved.  The solution may involve re-spinning the PCB; it may not be easy, quick or cheap to implement the solution; but there is always a solution and sometimes, just sometimes, it’s a really simple one.

You know what? I can’t answer the question…

I didn’t get a very good degree when I left university, for various personal reasons, but it’s never really affected my career, as I’ve learnt a lot more about electronics since leaving university.  I have a great deal of respect for people who spend more time in academia but sometimes even the most educated of people can be really daft.

Back in the day, Harris Semiconductor (now Intersil) made a non-isolated offline switcher, capable of a low voltage output at a few milliamps of current.  As long as the customer didn’t need isolation, it made a great solution for a bias supply for circuitry, for example.

I went to see one customer who had expressed an interest in this part and we discussed the merits of it in their application.  The company was a university spin-out and I met with the Technical Director (a Professor) and a young graduate project engineer.  It sounded a good fit until the Professor asked about EMI (Electro-Magnetic Interference).

I was well prepared: I had an example layout that met the German VDE standards for conducted emissions (this was before the harmonised EU standards and the VDE spec, which eventually became the EU standard, was the most demanding).  Ta da!

“No, I mean what is the EMI performance of the chip?” asked the Professor.

“Well, it depends on the layout; and in order to help you meet the conducted emissions standard, we’ve produced a sample layout that does…”

“Never mind the layout, what about the chip itself?” persisted the Professor.

Now, anyone who knows about electromagnetic interference knows that a switching converter generates interference but how bad that affects the environment depends on the layout.  With a neat layout and adequate filtering, you can meet the limits set out in whatever standard you are trying to meet.  If you have a poor layout, for example with long tracks acting as antennae, then you’re going to fail the limits.  I could see that the young graduate engineer “got” this but was too deferential to his boss to say that he was wrong.

How did I resolve this impasse?  Did I tell him he was a fool?  Did I embarrass him in front of his junior colleague?

To paraphrase Monty Python, ‘Brave Sir Martin ran away!’  I made my excuses and left.  “You know what,” I said, “I don’t think this part is suitable for you after all.  I’ll not take up any more of your time.”

It goes to show that there are some questions you just can’t answer, especially if an educated person fails to grasp a fundamental point.

Easter Eggs

Most evaluation boards or demos have a secret menu that, for example, gives you access to areas of the chip that need to be tuned in development but aren’t designed to be modified by the end user.  When a product is released, these menus are either deleted or disabled.  However, there are some products that have these menus still active.  Has anyone comer across these ‘Easter Eggs’ in their electronics goods?

Porting PMODs to Raspberry Pi

No customer updates this week but I did take a day off work and managed to get the MAX5216 SPI DAC to work with my Raspberry Pi.  I ported the example code from Maxim’s website to Python and got very excited when I connected my multimeter and could change the output voltage.

Little things please little minds!

I’ve just started work on porting the code for the MAX7304 I2C port expander PMOD board.  It’s a little bit more complicated than some of the other port expanders on the market and needed a number of registers to be set before I got one of the LEDs to flash.  Still, the demo code is well written and should be a doddle to port.

I’ll keep you posted!

Making the same mistake twice

We all make mistakes – after all, we’re only human.  The key thing is to learn from them.

I’ve made a few in my time.  Like when I improved my ZX81’s power supply by adding a linear regulator to drop the voltage so that the computer ran cooler.  I also decided to house this new power supply in a metal box which of course had to be earthed.  The other problem with the ZX81 was that the programs were loaded by tape and my machine was unreliable.  So I came up with the idea of using the speaker output from my hi-fi to improve the drive into the phones socket.  It looked good for about 40 seconds at which point one of the output transistors, which was now shorted to the earth via the new power supply box, went up in a puff of smoke.  Needless to say, I knew what had happened immediately and cursed my stupidity.

Although it was slightly less dramatic, years later I came across an odd problem with a customer board.  I said in my last post that it’s ideal to have a proper debugger where you can set breakpoints and so on.  However, we also used a debug application that connected via the serial port.  A bit like HyperTerminal but with a fancy front-end that gave you access to all of the chips registers and would allow you to navigate various the menu states without having to provide the key presses or infra-red buttons.

On this particular customer’s board, the serial debug interface was not working and according to the software engineers had never worked.  The odd thing is that the serial port appeared to be fine because the customer could use it to flash the code down to the board.  It wasn’t a big issue because the engineers to read the registers by looking at a dump of the memory map but it was definitely more convenient to have the register names rather than the memory addresses, so I wanted to find out why it wasn’t working.

A look at the customer’s schematic revealed the issue.  The hardware designer, instead of powering the serial port from the supply, had powered it from a GPIO pin of the microcontroller.  Presumably he wanted to use the micro to disable or enable the serial interface depending on the state of the GPIO pin.  The result was that there was just enough current to be able to flash code down to the board but not enough to handle the different baud rate for debugging.

I cut the track and put a wire straight to the supply and was then able to both flash the code and run the debug interface.

The hardware engineer moved companies, to their largest competitor, where he designed a board with another of our chips.  When I came to debug that board, yes you’ve guessed it, I could flash code but the serial debug interface did not work.  He had made the same mistake twice!

Needless to say, when he asked for a recommendation on LinkedIn, I ignored the request.

…but how do you debug the code?

Continuing the theme of board bring-ups, I did one a few years ago with a high-profile customer, probably the foremost manufacturer of LCD TVs in Europe.  We were the back-end scaling and LCD driving part of the design and Micronas were the front-end video decoder and deinterlacer.  They had sent over 3 FAEs to tune their video decoder whereas it was just me from our side.

However, it wasn’t just the FAEs that were unbalanced.  The customer had 3 hardware engineers and just 1 software engineer.  I had done my homework and got the latest software build for our part so I was pretty confident that we’d get the software running quickly and start knocking off their software bugs at a good rate.

I would normally insist on doing a schematic and layout check before the customer signed off the PCB for manufacture but I figured that these guys knew what they were doing, so I didn’t in this case.  As it turned out, that was a mistake.

I had unpacked my evaluation board and ROM emulator (this was before the days of JTAG debugging) and was raring to go when I noticed something odd about their board.  I go to plug in my emulator and find there is no debug socket to plug it in to.  When I asked where it was, they told me they didn’t put it on because they didn’t think they would need it.

So I asked the software engineer, “How do you debug the code without an emulator?”

“Oh,” he said, “I just flash it down and use printf debugging.”

Well, anyone who has ever debugged code knows that printf debugging is only really workable for small amounts of code or for where you really have no other choice.  To debug the amount of code in your average TV you really need to set breakpoints in the code, single-step through lines of code and be able to inspect variables.

Bearing in mind that this was the first prototype board and there are usually going to be hardware changes before the final hardware, I could not believe they had not put a debug connector on the board.  By all means, don’t populate it on production board or even have a break-off board.  It’s not as if there was any space constraint!

Well, I said to the 3 hardware engineers who were standing around twiddling their thumbs, “Take this board and de-solder the FLASH memory.  Then wire the address and data pins to this connector.”  After about an hour, they came back with the board.  I plugged in the emulator and the code ran nicely.  I could set hardware breakpoints and debug code quickly.

The story has a happy ending.  Not only did the board work well but it went on to be this company’s best selling LCD TV chassis ever!

Software or Hardware problem?

There haven’t been many interesting enquiries this week, so I thought I’d tell you about an interesting issue I had a few years ago bringing up a customer’s first prototype board.  Whenever a customer starts an embedded design, I like to schedule some time with them as soon as the first boards come back to make sure the hardware comes up alive and ready for the software development to start.

The day before the scheduled bring-up, I had a call from the software engineer to say that they had done some initial hardware tests on the first board and it seemed fine.  However, he had tried to run the software he had been developing and the emulator could not connect to the board with the debugger reporting an unhelpful error message.

So, first thing to do was to get a scope and look at the reset, address and data signals.  The scope was of a certain age; you could tell that by the monochrome orange display; but it had a facility to print the trace on the screen, so we could compare the signals from the evaluation board and the customer’s board.

On the evaluation board, we could see a nice reset followed by a burst of addresses and data as the code loaded and ran.  With the customer’s board, we got a reset, the start of the addresses as it jumped to the interrupt vector but then nothing.  Not many other clues except one of the signals appeared to be about 0.6V below where it should be.

So we dug out the schematic and chased it back to a transistor.  Although this was a low power micro with some extremely low power (in the nanoamps) power down modes the hardware engineer had put in a transistor to switch off the battery power if needed.  The hardware engineer disappeared for a few minutes to remove it from the board and lo and behold the emulator connected and the code ran happily.

The moral of the story is that although you may be getting error messages from the software debugger (which may or may not be helpful and informative) it could be a hardware issue preventing your code from running.  So get a fresh pair of eyes to check your schematic and layout to catch any omissions or errors before you commit to a board.

Switching Power Supply Design

Tricky things switching power supplies.  Not the ‘simple’ integrated FET switching regulators with internal compensation and all that jazz.  No, I mean the multi-phase PWM controllers with external MOSFETs and external compensation.

The datasheets are normally well written and there is usually a good simulator model or design spreadsheet that calculates the optimal values for compensation.  The real difficulty comes with layout and with parasitic effects.  I had a recent example of this and wanted to share it with you.

I had a customer who had seen a brief transient spike that oscillated for a few nanoseconds every time the upper FET (it was a synchronously rectified design with a low-side FET replacing the Schottky free-wheeling diode for better efficiency) turned on.  It appeared that the lower FET was also turning on briefly and the transient was ‘shoot-through’ where both FETs are conducting.  If this goes on for a long period of time it can be bad news as you are effectively shorting the input supply to ground.  However, in this case, it was a few nanoseconds so the worry was more the long-term reliability of the design.

The transient the customer was seeing was dVds/dt induced turn-on.  When one FET is turned on or off, a step of voltage is applied between drain and source of the other device on the same leg.  This step of voltage is coupled to the gate through the gate-to drain capacitance, and it can be large enough to turn the device on for a short instant.  The way to solve this is to slow down the dVds/dt of the FETs.

In the case of synchronous buck converters, the rising edge of the switch node is generally the node that must be slowed down.  One way to do this is to increase the upper FET gate drive resistance, to slow down the turn on.  Remember that with power FETs you have to charge the gate capacitance so you effectively have an RC circuit with a time constant and increasing the resistance increases the time constant.  Check the manufacturer’s data sheet but the value of this resistor is of the order of a few ohms.

The main disadvantage of this is that the switching losses are higher.  The other issue is that as well as slowing down turn on it will also slow down turn off (which is already much slower than turn on).  One way around this is to put a reverse diode in parallel to the gate resistor to allow a fast turn-off but a slower turn-on.  I this case, the customer could not change the board layout but if you are laying out your own board, it’s worth putting in a link for a diode if needed, at least for the prototype board.  I have also seen customers place a resistor in the bootstrap path to slow down only the turn-on speeds.

The ringing is caused by energy going back and forth between the gate-to drain capacitance and the gate lead inductance.  It is good to keep the gate PCB trace as short as possible.  Don’t ask how short is short!  Also take note of the layout recommendations in the datasheet.  For example, for this particular controller it recommends that Gate traces be run in pairs: UGATE+PHASE and LGATE+VSSP with trace widths at least 30mils thick.  Oh, and never run any of the sensitive signals under the phase (switching) node…

Apart from that, it’s pretty simple.