Silicon Valley Redneck

Another lost concept

So, CuriousMarc continues his efforts at getting his extremely-vintage HP desktop computer back in operation, even resorting to wearing his quasi-replica magic pants.

(The pants don't have the true 1970s magic, as they're not proper bell-bottoms.)

Anyway.  The most recent installment features a pair of vintage HP diagnostic probes: an HP 546A logic pulser and an HP 547A current tracer.  They didn't work for tracking down the problem at hand, but the principle is intriguing: use the pulser to apply a signal to a net, then use the current tracer to see which trace is actually carrying current; the trace with the current leads to whatever is shorting out the net.

Hm.  I wonder if anybody's refined this, maybe into something safe for boards with the latest generation of low-voltage logic...?

Apparently no.  Seems like the only current tracer probes around nowadays are meant for use by electricians, and are much too bulky for poking around on circuit boards (even low-density 1970s boards).  I did find a reference to someone (since deceased) who'd had a go at making some sort of 547A knockoff, years ago, for his own use.

Well!  Seems like this is yet another thing to put on the Maybe-A-Product-Someday list.  Gotta make the probes (including the magnetic pickup for the current probe) pointier nowadays.  And... methinks selectivity could be improved by synchronizing the current tracer to the pulser, so it'd have a sample window just when the pulse ought to be happening.  Maybe the pulser could have selectable output levels, perhaps 1V, 2V, and 4V (in case anyone's still using 5V-tolerant logic) [see addendum].  And, selectable peak current, or pulse energy, or something?

Limitations, though... this'll play nice with 2-layer boards, or 4-layer with the inner layers used as ground planes, but utility falls off as the layer count increases.

Anyway, not something I'll be playing with anytime soon.  Maybe when I have a bunch of focused, brain-functioning free time, long about the 37^th of never.

(Alternative approach to finding the short: apply a low-voltage, high-current DC source to the offending net, and use a thermal camera to see what traces get warm.)

Addendum:  Seems the pulser probe accommodated a range of system voltages by the simple expedient of running off a user-provided power source and being able to handle 3~18V for TTL or [CD4000-series] CMOS.

Now that's just wrong.

Sumdood hollowed out a (defunct?) Osborne 1 and replaced the innards with a RasPi running an emulator, plus an Arduino to translate the keyboard.  (Via Hackaday, via Digi-Key.)

And a color LCD.

Y'know, you can still buy an actual Zilog Z80 chip.  Brand new, like.  For authenticity.  And whatever no-longer-available LSI chips were on the original motherboard could be emulated in small FPGAs.

For an extra challenge, the whole dang motherboard (power and analog bits excluded) could be emulated in a moderate-sized FPGA.  Stick a dinky PCB under it, with voltage regulators and some interfacing, and you've got replacement computer guts.

That, kids, would be a proper project.

Actually had a productive week.

Mainly, the prototype hardware for a big project arrived - shipped from, apparently, China on Tuesday, and I got my hands on it Wednesday.  That meant:

Smoke test!!!!

Which went well; on application of power, the regulated voltages came up as they should, and there was no smoke to be seen.

The on-board MCU, which handles supervisory functions, programmed normally via the Tag-Connect footprint (once I removed the solder; I'd already corrected the library footprint to turn off solder paste and include "finish" (i.e., gold if available) on those pads, but I did that after the Gerbers went out.

Then, various sorts of functional tests.  Normal operation involves a System-On-Module (from Olimex), running Linux, but I don't want to rely on that just yet.  So, test the USB hub and peripherals, I chopped the "B" connector off a USB cable, added a connector to mate with the applicable SOM header, and plugged it into my workstation.

Success!  Everything seems to come up OK, at least to a first approximation.

Then it's time to plug in the SOM.  Hook up a serial cable for the Linux console.  Insert a memory card with the latest image from Olimex.

Well... it boots, but I can't seem to get the configuration right.  It's not finding the USB, and the Ethernet isn't working - when I plug in the cable, the LEDs come on, but there's no communication between SOM and PHY, for some reason.  Grrrr.

Try the previous-edition Linux image.  Not much better.

Fiddle some more.  Look closely at the schematic, and realize that I've swapped USBD+ and USBD- between the SOM and the hub.  Wait, then how did it work with the hacked cable?  Maybe the cable has the colors swapped, and the errors canceled out?

With the aid of a couple of patch wires, I get something that looks a little more promising, but Linux is still not finding the high-speed hub.  Look at the schematic again.  USB1_ID is pulled down with a 10K resistor, same as in the eval-board schematic.  But!  Digging through layers of documentation until I get to the processor chip's datasheet, I find that the USB ID pin should be either basically open or basically shorted to ground.  So maybe the eval board really has 10Ω there, not 10K?  Remove the resistor, substitute a solder blob, and hooray!  The hub (2 chips, cascaded) and the supervisory MCU enumerate!

Alas, the Linux image I'm using now (I think I was back to the current edition at this point) doesn't include the cdc_acm driver, so I can't actually talk to the MCU.

Next morning, fetch from the client the eval board and the as-edited Linux image that their software guy was using to talk to the first-edition (lash-up) prototype.

USB enumerates, I can talk to the MCU, and things seem to be working!  Yay!

But still no Ethernet.  In fact, I'm no longer getting so much as a LINK light.  Eh?

Grab a USB Ethernet dongle, plug it into the workstation's hub, and try connecting to that.  Link light, speed light, and, hey presto!, communication!  Must be something's gone wrong with the cable and/or port that I was trying to use.

A bit more fiddling, and more of the board (as much as I've managed to test so far) is working.

'Tis unfortunate that it has those two little patch wires, but such is life.  Minor rework on the five prototype units is no big deal.  The main board will need a respin anyway, for mechanical reasons: the power connector and the Ethernet connector are both turning out to have Issues with regard to the height of the board stack, the depth of the enclosure, and cable bend radii.

Also, there's a rogue signal trace that I somehow missed seeing in the artwork, reducing the available copper for one of the high-current paths.  I may have to stick a bus-bar on that part of the board (which was designed to accommodate bus-bars, just in case).

Hey, as long as the prototypes get through their functional & environmental tests without too much more rework, a few fiddly & localized changes to get to the production model won't be much of an issue.

This is the good sort of project: not only do I get to do cool stuff, but if the product becomes a commercial success (it's primarily for the client's in-house use, but is potentially a product in its own right), there'll likely be a fair amount of follow-on work over the coming years.

Update: Initialization of the SOM is a bit odd; seems the two Ethernet ports share a MAC address (which doesn't really matter, as they wouldn't ordinarily be plugged into the same LAN, and besides the actual application board only has one PHY and connector), and the persistent-net.rules file starts out configuring eth0 and eth1 based on the MAC address of the board on which was originally created... but if you move the memory card (or copy the image) to a different SOM, lines will be added to that file to configure the newly-discovered ports as eth2 and eth3.  This is presumably iterative.

So, the master image will need the rules cleaned up, so that whatever SOM it's booted up on will end up with eth0 and eth1, whereof only eth1 is actually functional.

But that's software stuff.  The hardware is what I'm meant to be bringing up at this point.

I still need to do the great test of power handling.  Actually, multiple tests.  Does the master power switch remain reasonably cool while carrying 20 Amps?  Do the per-channel switches properly handle 1 Amp each?  Do I have enough copper to distribute the current?  Will the heavy copper of the inner layers do a good enough job of distributing the heat away from the hot spots?

On this last point, I have some confidence: after the USB hub (high-speed, two 7-port chips) enumerates and starts consuming power, the entire board becomes somewhat warm.  The power switches are more obvious hot-spots, but they shouldn't be dissipating much, as the FETs were chosen for, among other things, low ON resistance.  Still: maximum total dissipation in the power-path components is around four and a half Watts, and then there's the resistance of the copper itself to be taken into account.

Hm.  For a full-load test, I'll need a many-channel dummy load that can handle a whole bunch of Watts.  Probably waterproof a bunch of resistors and stick 'em in a cauldron of water.  Easier than bolting them to a tunnel-style heatsink (assuming I could find one!) and sticking a fan on it.

Hmph. Seemed like a good idea at the time.

Well... I had a go at using the EAGLE v7 hierarchical design feature.

As matters currently stand, it falls considerably short of being useful.

Yes, it's a handy way of organizing the schematic, and handling replicated structures (I need to deal with eight copies of one module, each of which has four copies of a sub-module).

But....

It doesn't help the least friggin' bit with replicated layout.  I'm thinking it actually makes the layout process even more awkward.

The resulting reference designators are appalling (QUAD2:CELL1:R34, for example).  They can't be re-sequenced into geographical order, but I guess that's OK, because there's no way they could be included on the silkscreen, and putting them on an assembly drawing would require some serious miniaturization.

Trying to debug a board...?  This could get very annoying, very fast.

Then there's the question of whether the assembly house will accept that refdes format.  And whether the BOM and pick-and-place export utilities I've been using will deal with it... or indeed with a hierarchical design.

Also, there doesn't appear to be any way of selecting a hierarchy object per se, so that its components can be moved apart from the mass and onto a layout template.  Highlighting in the schematic and alt-tabbing (the switch view button would remove the highlight!) to the layout gets a somewhat useful indication of what's what, but the moment you select the move tool, the highlight goes bye-bye.

So, nope.  Not useful for what I'm trying to accomplish.  Back to the old flat schematic, with eight copies of probably a B-size sheet with a complete four-cell cluster plus the common stuff.  That'll be enough of a headache, but at least the reference designators will be a sane length.

This also means that the next phase of the project will be more laborious than I'd hoped, but, hey, it's hourly.

(Maybe I'll rummage around the 'net a bit later, and see if there are any useful tips for actually using the hierarchical features.  Should I find anything to change my mind, I'll post an update here.)

Update: Seems the hierarchical thing was half-implemented, not to the point of actual usability, at the time Cadsoft was acquired by its previous corporate overlords, but Marketing decided to declare it a feature anyway.  I did, however, find a useful tip on how to do what I actually need to do: lay out the cell as a separate design, then import it into the overall design 32 times.

Know what'd really be helpful here?  The ability to select a group in the layout editor, and lock all the elements in it together until further notice.  That way, each cell layout could be moved around as a unit.  This would be especially useful if the lock persisted when the cell design was imported into the greater design.

Update 2: I promptly find two annoyances with the "save cell as its own design, then import repeatedly" approach.

First, there doesn't seem to be a way to auto-sequence a selection of nets, so that, e.g., IN, CONTROL, and OUT would have "1" appended on first importation, "2" on the second, and so on.  There's the opportunity to rename nets during importation, but it's annoyingly manual.

Second, each imported design starts on a brand-new schematic sheet, which, when we're importing little cells, brings us back to the classic annoyance of trying to move schematic fragments from one sheet to another, so we don't wind up with a 50-page schematic.

I have the feeling I'll end up importing four cells, merging the schematics into one B-sized sheet, combining the layouts into a quad-cell, grafting in the per-quad circuitry, then importing the quad eight times into the overall design.

I'm also getting the feeling that this may end up being a six-layer design.  I'd better get a handle on how much space I really have for the stuff that goes between the cells, to see if I can loosen things up a bit and get back to four layers.

...Oh.  I'd made the cell layout 0.4" wide, because it uses 4 pins on a 0.1" pitch stacking header.  But the actual pitch required is closer to 1".  [Edit: Sorry; the final connector row is on 1" pitch, but there are two staggered rows, so the cells are on 0.5" pitch, overall.  Still works with all the cells being on the same side of the board.]  That do free up some space; I can maybe use a single-row stacking header, and putting all the cells on one side of the board might make life easier.  Or, I can get away with using a components-both-sides layout for each cell.  Anyway, it should be easy, but I need to get my strategy in order first.

Demo!

I packed up the dog and pony again this afternoon (after confirming that the gremlin was, if not banished, at least propitiated) and headed off to the client site.

This time everything worked!  In front of the client, even!

And now I have a bit of slack in that project's schedule, since the guy who'll be doing the application software is currently tied up working on hardware (with wrenches and whatnot), so I get to hang onto the test platform for a while yet.

Next priority is some documentation, then some patching-up of hacks made to the hardware.  Then... well, there's a fair long list of stuff I really should get done in the next three weeks.  Not to mention stuff for other clients.

Oh, and two new gremlins turned up this morning.  One I bypassed temporarily; the fix seems to involve adding bulk capacitance (and I sure hope I can avoid electrolytics; this thing is supposed to be reliable).  The other is yet another oddity in the Linux USB stack, cured by a reboot.  (The long-running oddity is a tendency to decide that, for example, an ACM device should appear as /dev/ttyACM17 instead of the more obvious /dev/ttyACM0; the one that bit today was a sudden belief that the USB port didn't have enough current available to power the same dang collection of peripherals it had been powering all week.)

For now, though: I'm tired, frazzled, and chronically overcaffeinated.  Also, it's 90 degrees horribly Fahrenheit.  Time to vegetate for a couple of hours, while guzzling ice water.

Ground loops!

Can be exciting!

Or, as in this case, merely frustrating.  I think the gremlin I've spent the last week chasing was actually a ground loop, of the electrical variety.

See, there's this engineering lash-up, prototyping the various subsystems of a product under development.  Being as how it's a lash-up, with each subsystem on its own board, there are wires everywhere.

There are four boards in this lash-up: one of type A, one of type B, and two of type C.  Various boards of type D (or D', D'', etc.) may or may not be connected to the type C boards.

There's been a Heisenbug afflicting board C0, and not board C1.  Replacing C0 changes the problem, but doesn't actually fix it.  So... are all the type C boards faulty, except for the enchanted C1?  Or...

The type C board has a power connection (power and ground), and a data connection (USB).  There's a quad UART on the board, powered from the bus (the power connection is for some medium-power drivers).

Certain sorts of activity cause the UART to drop off the bus, and then re-enumerate.  This only happens with the power supply at or near rated voltage; running at half voltage, there's no problem.

For the past few days, I've been chasing the notion that the UART (or the Linux FTDI driver) freaked out if certain modem-control inputs (in particular, DCD) changed too often; some of the early type C boards had interesting problems that led to, e.g., 1.4 MHz square waves on all four DCD lines once a certain voltage threshold was crossed.

But, this hypothesis really wasn't consistent with what I was seeing this afternoon.  It really seemed to be position-related.  And... um.

The one thing different about the C0 location?  The power wiring is longer than C1.

So I added a second, shorter ground wire to C0.  Now... it seems to be behaving itself.

Still gotta do more testing.  A bunch more.  But it looks like certain switching events, with the supply at full voltage, created big enough current spikes to cause disruptive ground bounce on the USB cable, leading to bus errors.

In the production item, of course, the USB will all be on the one unified board, running down the center, with a nice quiet digital ground plane under it, and the power for the drivers will be routed around the periphery, with strategic plane cuts to avoid this sort of thing (as well as ground offsets when there's a lot of current flowing).

Update: As currently wired, the problem reappears if I crank the voltage up to 15% above nominal.  Action plan for Monday involves re-wiring, using heavier wire for the ground, and adding some inductance in the supply paths.  The gadget is designed to operate from 60% below, to 25% above, nominal supply, and I'd really like to see the lash-up perform over the full range.

Update 2: Oho!  This would also explain why it was sometimes bombing when I connected a ground lead to one of the ground test points.

The pony kicks his heels up while the doggy does his trick...

Yeah, had to put on a show this afternoon.  On a Monday.  At the client site, so it meant moving the test program from my workstation to my laptop, and packing up the test-bed hardware.

First oopsie: the control MCU enumerates correctly as /dev/ttyACM0, and I can open a PuTTY session connected to it, but pounding on the keyboard has no effect.  WTF???

After much power-cycling of the testbed, cable plugging and unplugging, and so on, I realize that I'd been pounding on the wrong keyboard.  Putting the laptop on my desk for the process was maybe not the best move; I kept getting mice and keyboards mixed up.

That having been sorted out, I proceeded to box up the hardware.  Second oopsie!  I left the mini-USB cable plugged into the hub board.  It had enough leverage against the edge of the box to pop the little SMT connector right off the board.

Well, that's why we make the boards in threes.  One for the client, one for me, and one for Murphy, right?

So I grab USB Hub Board S/N 2 and swap it in, then quickly power up the unit, plug it into my lab PC, and confirm that everything still enumerates correctly.  Off to the client site!

Discussion, display of hardware, setting-up of laptop, connecting of cables!  Send the first few commands to the control MCU: all appears well.  Run the test program.  Issue a few commands....

Third oopsie: the power LEDs on the remotes go out after a couple of commands.  Everything that goes through the UARTs (comm or modem control) seems to have stopped working.

Much fussing and fiddling.  Eventually discover that, shortly after I started doing things with the UARTS, there was a flurry of USB errors, and the UARTS disconnected and re-enumerated, which didn't exactly preserve my program's connections to them.

After much further fiddling, I dug a compact USB 2.0 High-Speed hub out of my laptop case - good thing I had one in there, and good thing it was of the High Speed persuasion! - and used that to connect everything.

Still strangeness, but eventually I managed to get it working well enough to demonstrate basic operations.

Now I gotta figure out what was going on with the USB: is there something wrong with the second USB hub board, is it something to do with the laptop, or was it just the built-in crisis detector at work?

It is actually rather important that the USB hub work properly, as that and the UARTS have to end up on the same grand unified board with the control MCU and the power circuitry, comes the time to turn this into a product.

Oh, well.  The client got to see something working, anyway, and there's a pretty good chance I'll have the glitches fixed by the end of the week.

Update: It appears that the hub is fine.  The UARTs may or may not have a problem, and the Linux driver for the FTDI UARTs may or may not have a problem.  There's some issue with the modem-control signals, and some sorts of activity on those signals triggering error status, which doesn't particularly make sense.

Also, there may have been a mechanical Heisenbug in the data path to one of the UART chips: a poor solder joint may have made it sensitive to vibration.

It's now Friday morning, and I'm still bashing my head against this... though I now have seven out of eight ports in the test setup apparently working (port 0 goes to permanent error status if I turn on RTS, though it seems to be OK if I exercise the modem-control signals from GtkTerm).

Well. That was Interesting.

Over at Toasterco, my understudy had been struggling for a couple of weeks with a manufacturing problem; a batch of controller boards (the crazy complicated, do-everything model with zillions of little SMT components) made by a new contract manufacturer had a high failure rate, and the failure mode made no sense.

Basically, all signs pointed to the I²C bus being wedged LOW (both signals).  This led to various trouble.

So, I spent a couple of hours over there - hey, their lab is air conditioned!  Things continued not making sense.  The SDA and SCL lines were clearly being actively driven low, showing about 0.25V with the normal 10K pullups to 3.3V, and maybe 1.2V with a 330 Ohm pullup.  But then....

The I²C bus has a level translator between 3.3V (the MCU and a few other things) and 5V (a parallel port that really does need to run on 5V).  Were I designing the thing today, that wouldn't be necessary, as there are now 16-bit I²C I/O port chips with split supplies, so the bus can run on one voltage and the I/O on another.  But that's now, and the board was designed then, and it needed the bus bridge.

On the 5V side, there are two pullup resistors, as one might expect.  But.  Wait.  Er...

Know what you get when you place a pair of 0402 resistors next to each other on a 25 mil grid?  Right!  It's kind of hard to tell which pads are what.  And the 0402 resistor footprint in my library at the time had "part goes this way" markings in the assembly drawing, but not on the silkscreen.

So, yeah.  The resistor pair was rotated 90° from its correct orientation.  One resistor was between SDA and SCL, while the other was between 5V and 5V.  Result: SDA and SCL on the 5V side drifted LOW by default, causing the translator chip to drive them low on the 3.3V side.

Oh, now this is just inexpressibly cute.

Still a-pokin' at that electrical apparatus with the KV30 in it.  (No, it doesn't operate at 30KV.  Different project entirely.)

The analog aspects show definite signs of suboptimality, so naturally I start looking more closely at the power supplies.  Well, the 3.3V power supply, since that's the one that counts.

This dingus runs off an inconveniently high input voltage (though well in SELV territory; it's merely out of bounds for my usual favorite regulators).  I'm using a switcher to get down to 5V, and a little teeny linear to get from 5V to 3.3V.

First thing I check, during bring-up: do I get 5V?  Yes, and well within tolerance.

Next I install the ferrite bead that connects the output of the 5V regulator to the input of the 3.3V regulator, and check again: 3.3V right around nominal, and 5V still healthy.  All this according to the nice accurate bench multimeter.

But, once I start using the ADC, I see unstable measurements.  Since the 3.3V supply is the ADC reference (I have a plan for compensating for supply tolerance, but that comes later, and it can't deal with instability), I stick a scope on the 3.3V supply.

Oh, looky!  A sort of repetitive double-pulse spike, around 100mV peak to peak.  That'll make a right hash of things.

There's... something kind of similar on 5V.  But much less spiky.

Awright.  Replace that bead with a real inductor.  Increase capacitor values.

Now the 5V supply is dang near clean.  But the 3.3V is as spiky as ever.  And it does seem to be synchronized to the 5V switcher.

Tossing a 50mA static load on the 5V rail gets a tidy 1.5MHz ripple on the 3.3V supply, while the 5V looks clean.

The linear regulator is amplifying the noise?

Let's have another look at the layout, shall we?

...Oh.

When I did the layout for the development board, I went with a 2-layer stackup in the interest of getting the boards quick & cheap so's I'd have something to play with.  I also got a little casual with the layout of the linear regulator and its capacitors, and then didn't give it a critical going-over after the autorouter had run traces through that area.

There's a slot in the solder-side (where those two caps live) ground fill, nigh a quarter of an inch long.  The output cap is connected to the plane right near the ground via for the regulator chip: no problem.  The input cap, though, connects right in the middle of the other side of the slot, close to the switcher's noise.

So... maybe rotating the input cap so it shares the output cap's ground connection (close to the chip) will correct the problem?

Nope.  Still all quiet on the 5V front, and 100mV of switching-correlated noise on the 3.3V.

Grumblegrumblegrumble.

Well, that layout issue didn't make a whole lot of sense at 1.5MHz anyway.  At 150MHz, maybe, but I'm not dealing with that here.

Back to pondering.

Update: What the...?  Ripple at the linear reg output cap is lower by almost an order of magnitude.

Um.  One side of the 3.3V trace runs alarmingly close to the switcher's inductor on its way around the end of the board to its destination.  (Another, autorouted trace is even closer.)  Aaaand... yeh.  Horrid noise on that end of the trace.  Which is the end that connects to everything important.

Guess the next thing to try is changing a few of the bypass caps along that path  to something stiffer.  Or, perhaps, cutting the trace and running a patch wire 1/8" south.  Ugh.  Cut & patch is annoying, but I think it's the best next step, really.  And at least the trace is a generous 0.010" wide, not a scrawny 0.006".

Update 2: Rerouting the trace and adding a bonus microFarad downstream each reduced the noise by about a factor of 2, so now it's down around 25mV.  I expect the power to be a fair bit cleaner on the 4-layer life-size board... and there'll certainly be a respin in any case, as the final form factor has yet to be determined, never mind the type of connectors on the ends of the board.

ADC performance now seems consistent with a moderately noisy power supply.  I may add an extra stage of filtering on VDDA in the next iteration, in addition to general cleaning up.

Meanwhile, I can get back to working on the firmware.  Maybe I should first populate one of the piggyback boards, so I can test some real-world I/O functions.

Well. Isn't that special.

If you're debugging an application on the Kinetis KV30 MCU (and, I'm guessing, other members of the family) using the on-chip debugger...

...And you're generating PWM using one of the Flex-Timer Modules...

...And you hit a breakpoint...

...The timer ceases to generate PWM.  You'd think: hardware-type peripheral continues running while the CPU is stopped at the breakpoint.  But you'd be wrong.

So far, I haven't seen it stop with the output HIGH; if the behavior is consistent, with the output always LOW when at a breakpoint, it's possible (for some applications) to design around that, and not have adverse hardware consequences when a breakpoint is encountered.

But, if some hardware design optimization dictates that the "safe" condition is output-HIGH, then hitting a breakpoint could result in a ruptured smoke bushing.

I recall running into some related issue when debugging on an AVR... over a decade ago.  But the FTM is an 8-bit peripheral grafted into a 32-bit MCU, so what should I expect?

(It's also possible that I have something misconfigured at the library level, given that the output is waking up at the default-configured duty cycle and my attempts to change it on the fly don't appear to have any effect.  Once I sort that out, I'll have to address the problem of the high-level library taking an integer percentage for the duty cycle, when I really need to have finer-grained control.)

Update: OK, so I was missing something.  Behavior is configurable; there are four BDM modes, and BDM Mode 3 is what I was expecting; the others are meant to go "safe" at breakpoints.  So that's working now.  Yet to be sorted out: why the duty cycle isn't updating, and/or why some configuration options cause the FTM to generate an unhandled interrupt upon initialization.

Update 2: Awright, got it updating and using full resolution now, mainly by bypassing the peripheral-driver layer after initialization.

Import the necessary:

#include "fsl_ftm_hal.h"

#define FTM0 (g_ftmBase[0])

During initialization:

  // Set the PWM divisor to a known 4096 instead of some calculated value
  FTM_HAL_SetMod(FTM0, 4096);

To set the actual PWM pulse width in clock ticks:

	  FTM_HAL_SetChnCountVal(FTM0, 2, pwm1val);
	  FTM_HAL_SetChnCountVal(FTM0, 4, pwm2val);

	  // Now trigger the update of the actual FTM registers
	  FTM_HAL_SetSoftwareTriggerCmd(FTM0, 1);

Seems to be doing what I want.  The documentation isn't very clear, and the peripheral driver is missing that all-important "change the dang duty cycle" function - if you're using that level of driver, you have to call FTM_DRV_PwmStop and then FTM_DRV_PwmStart, because repeated calls to FTM_DRV_PwmStart don't result in actual changes of duty cycle.  Also, if you're using multiple channels, you have to call FTM_DRV_PwmStop in between the ...Start calls for the channels.  Or something like that.  It's all very confusing, really.

Life in the electronic age

Several years ago, my father bought himself a Saab convertible for his Monday-morning commute.  (At the time, he was actually commuting to work a few days a week, now he's down to just Monday mornings.)

Sometime last year, it started draining its battery in less than a week of standby time, so the once-a-week drive was no longer enough, and he keeps it on a trickle charger.

I was over there this morning, and the latest development was: it don't work no more.  Doesn't respond to the (electronic) key.  Everything remains locked (except for the doors, which he hasn't been in the habit of locking).

Hmmm.

Battery voltage is 13.25 while on the charger, dribbling off quite a bit faster than I'd normally expect when the charger is removed, but perhaps good enough.

Has the security computer gotten out of sync with the transponder in the key?  Or has it just temporarily misplaced its mind?  What happens if we disconnect the battery, wait a few minutes, reconnect it, and try again?

Or - happy thought! - surely there's a second key.  Does that work?  He goes off to fetch the spare key.  Voila!  We have a started car.  Now... how to re-introduce the first key, given that we have one-each working key in hand?  Apparently the local Saab dealership is long gone; who else would know how to do this?

Meanwhile, we'd both been trying to figure out how to extricate the metallic backup key (doors only, if memory serves) from the bulky plastic housing of the eKey.  I finally apply enough force to dislodge the one from the key I'm holding (the not-working one).

There's a little notch that looks like it's for prying the housing open, perhaps using the tip of the metallic key.  So I do that.

Oh.

There's a CR2032 coin cell in there.  Key's prolly just got a dead battery is all.

Ya know, in my day ya never hadda worry about your key's battery going dead!

Yet another thing needs replacing

My Bluetooth speakerphone, a bargain-basement model to begin with, has never been good about battery management.  If it's not charged for a while, it'll start making "bloop?" noises at random times, which I suppose is meant to be the low-battery indication.  Then, once I've decided to charge it, it turns out to be finicky about the charger; plug it one of the cheap two-hole chargers that I can use for just about anything else, and it apparently doesn't charge, though there's no real indication as to what it thinks it's doing.

Anyway, today it developed a new annoyance.  It made the "pling!" noise that it makes when the switch is turned to the OFF position... and, apparently, turned itself off.  Turning the switch OFF and back ON woke it back up, but then, several minutes later, it did the same thing again.

I don't feel like trying to fix it, given that the slightly upmarket model now costs $20 (plus another $6 to get it delivered tomorrow instead of the day after), so I've ordered the better one.  Apparently the new one, instead of randomly making "bloop?" noises when the battery is low, will randomly announce "Hey, the battery is 37% charged!", or something to that effect.  Anyway, more informative.

Now, here's a crazy thought: why don't Bluetooth speakerphones have some protocol whereby the phone could read the status digitally, and then an app on the phone could report things like battery state, whether it likes the charger, and so on?  Maybe the app could even be used for fiddling with settings, instead of having just the buttons on the speakerphone and some non-obvious way of using them for setup.

Update:  The new one seems pretty decent, though I haven't actually received any calls in the car, so I haven't tested the essential speaker-phone-ness of it.  Gotta figure out how to disable what I assume to be alerts for going in and out of coverage: bloop, bloop (I have the "play a tone when this happens" turned off on the phone, but the speakerphone seems to be making its own sound for the event).  When I switch it off, it emits a two-note sequence which is distractingly the first two notes of the Helston Furry, and I keep expecting Morris dancers.

In which I throw out a design idea

There's money to be made on this, but not likely by me, so I'll just throw it out there.

A couple of days ago, I had to fix my parents' TV.  Again.  The symptoms, as described over the phone by my mother, were horribly baffling to anyone not familiar with the modes of the remote.  As it was, I kind of figured one of the three inappropriate mode buttons had gotten pushed somewhere along the line, and it was maybe trying to control the nonexistent VCR or perhaps the sprinkler system instead of the actual cable box.

And, as expected: once I was there, I just had to push the "AT&T" button (instead of "TV", "DVD", or "VCR" or whatever the options are), and it commenced to control the cable box (and, minimally, the TV), as normal.

(My father has long refused to learn how to operate a TV set, preferring to read a book.)

So here's the idea: instead of having non-indicative soft mode buttons on the remote, have a rotary selector switch with a big honkin' arrow pointing to the selected function: "TV SET", "CABLE BOX", "DVD PLAYER", "STEREO", whatever.

Either that, or stop making every remote have the stupid modes for controlling other appliances, and just go back to having one, clearly-marked, remote per appliance.  But I guess that would be too easy.  And appliance manufacturers would have to mark their remotes: "PANASONIC TV SET", "AT&T CABLE BOX", "SONY DVD PLAYER", "MAYTAG WASHER", and so on.  And all it takes is one clown putting out modal remotes to re-introduce the confusion.

So: who's gonna make the universal remote with the big comprehensible selector lever?

Afterthought: Another thing that'd be nice for universal remotes?  A USB port, or Bluetooth, or some such computer interface for configuration, plus a configuration utility.  Instead of trying to look up, e.g., your TV set in a list of models to find the right magic configuration code, and then having to push the magic button sequence to enable tv-set configuration so you could enter the code, you'd just connect to your PC and run the configuration utility to do the lookup and update the configuration (alternatively, for Linux users, you'd go to the manufacturer's website, do the lookup, and save the resulting configuration file to /media/FoobyRemote3567/TVconfig.xml).

Annoyance

That toaster controller, with the FPGA in it?  The project with the hard-to-implement spec?

I came to the conclusion that, at a particular time, I need to dump an accumulator.  Actually, I need to duplicate the accumulator, and dump the duplicate; the original needs to operate as before.

This accumulator is tracking the sum of things in a 200-sample-cycle window.  So, there's a 200-stage shift register, and at each cycle, the accumulator adds the current input and subtracts the input of 200 cycles ago.

Dumping the accumulator itself is easy; just needs a couple extra lines in the Verilog.

The shift register that implements the delay?  Well, it's constructed using the Xilinx "Core generator" tool.  I'm offered the option of reconfiguring it with an SCLR input: deal!

And yet, it doesn't appear to work...?

Oh.

SCLR synchronously clears the last stage of the shift register.  Not the whole thing.  Oops.

In fact, the shift register turns out to be built of SRLC32E, which has no clear input.  The final stage is implemented as a single flip-flop with a synchronous reset input.

Rowrbazzle!

This leaves me with a couple of options that spring to mind: either laboriously (or maybe with a script, or with some o' that fancy Verilog trickery that I've managed to forget in the last few years) build up a 200-stage shift register out of flip-flops (and worry about how many are available at this point), or fake it by gating the output to zero for 200 ticks beginning with the reset event.  Maybe the second option makes more sense, despite the evident lameness?

Heisenbugs, again

Working on a project that involves a Spartan 6 FPGA.

Features that used to work had recently stopped working.

I hadn't changed the Verilog code for anything close to those features.  (I checked against the repository.)

In tracking down one of them, I created a pathway to the outside, so I could keep an eye on the contents of an internal register.

It promptly started working.

Looks like yet another case of Xilinx's toolchain optimizing out things that really need to be there.

And we don't have any sort of test automation for this project, so regression testing kinda isn't happening.

Well, the full debugging path was rather cumbersome, but I've replaced it with a spurious use of the register contents.  We shall see....

Update: Bouncing back and forth between projects, I find that the networking issue I've been trying to track down (in the mess of third- and fourth-party RTOS+networking code) is also a Heisenbug; dropping just the right sprintf in just the right place makes it work almost every time.  I suspect some wonky race condition, though such are supposed to be impossible in this context.  Grrrrr.

Update 2: Bounce to FPGA project again.  Could it be a timing problem, and not miscompilation?  Timing analysis is verbosely uninformative.  Look back at source code for the section that's not working at the moment.  Um.  That section is clocked at 10 MHz.  The 100 MHz and 300 MHz sections seem to be OK at the moment; how is logic that has 100 freaking nanoseconds between ticks not working?

(Thinks back to the Olden Days when clocking logic at 10 MHz was fast....)
(But at least you could put a scope probe on it!)

Update 3: FPGA problem sorted.  A key signal was crossing from the 300 MHz domain into 10 MHz.  There was a synchronizer, but apparently it wasn't working.  Or maybe the transition detector just wasn't working in the 300 MHz domain, though it was simple enough it ought to have worked.

Meanwhile, on the other project, it turns out that the problem isn't in fact fixed-enough-for-now, and furthermore there's a problem with configuration memory getting corrupted; the latter issue is possibly architectural in nature, and I haven't really looked at that part of the inherited code yet.  Aieeee!  And the first project (the one with the FPGA) has just sprouted a fine crop of spec clarifications and possibly revisions.  Wowf.

Aard-Wino strikes again

So I've got this gadget, and for convenience it's got a built-in nano-Arduino, or at least an ATmega328P with the Ardunio bootloader installed, and running at 3 Volts-ish and accordingly 8 MHz using the internal oscillator (to save 70¢ and a few square millimeters), and...

Well, out of laziness, I'm using the Adafruit NeoPixel driver to talk to a string of WS2812B addressable LEDs.

Took a bit of fiddling, and for some reason they want 400 KHz instead of the expected 800, or at least if I specify 800 KHz nothing happens, while at 400 they work...

Except that if the supply voltage is a little high, and the temperature is a little low, things get all squirrely, and I've been trying things like increasing the series resistor in the data line from the MCU (helped) and adding a monster bulk cap across the LED-strip supply rails (helped), and...

Well, none of this really solves the problem, so I decided to take a closer look at the timing, though my scope tells me the data rate is exactly the specified 400 KHz.  Maybe I need to fiddle with the parameters?

So I start looking at Adafruit_NeoPixel.cpp, and where NEO_KHZ800 is used, and.

Um.

There's a comment.

Running 800 KHz on an 8 MHz part requires special low-level bit-bashing code, which is implemented only for ports B and D, those being where standard Arduini keep their DIO pins.

My LED data pin is on Port C.  Which isn't supported at all.

So when I selected NEO_KHZ800, the driver did Nothing, because it didn't have the code to handle that data rate, at my MCU's clock frequency, on my nonstandard choice of pin assignments (it happens to be on the right side of the chip, so there).

When I select NEO_KHZ400, it mostly works despite being entirely the wrong data rate by a factor of 2.

Guess I need to copy the block of code for Port B, set it to handle Port C, and tweak it appropriately, 'cause I'm sure not adding a patch wire to that QFN.

Update: Yup.  Seems to work.  Now to stick one of the reprogrammed prototypes in the freezer for a while.

Another useful chip

From Micrel: MIC2876, a synchronous boost regulator with bidirectional load disconnect.

Just built up a test board (1/2" by 5/8", dominated by the input and output headers; actual circuit about 3/8" square) and verified what it does:

• When it's operating, it steps 1-cell Li-Ion voltage up to 5V (or other combinations; this pair is what I want it for), with minimal fuss and reasonable efficiency.
• When the ENABLE pin isn't being driven high, it disconnects the load from the supply.
• It operates at a decently high frequency, so the components can be small.

So, when you'd like to have a boost circuit, but you're worried about that pesky business of the input having a straight path through the inductor and rectifier to the output... this is a handy solution.  Boost regulator and power switch, all in one!

Mind you, there are also applications where you'd actually want a boost regulator whose "off" output was at supply voltage; I had one of those a few years ago.  The requirement at hand isn't one of those.

Update: With a 500mA load, and the particular 1.5µH, 1008 inductor I picked, efficiency is about 75%, and the little board gets rather alarmingly toasty.  I've got a 1µH part of the same footprint and lower resistance that I can try, later.  If I end up using this thing in the actual gadget, I may need to resort to a bulkier inductor (for which there'll be some room, on the back of the board, if I push some other stuff around).  I still need to get a handle on current demand (peak, average, and how long the peaks last) for the application.

So, I spent all day Thursday...

...at a Freescale event in Santa Clara, picking up information on, mainly, the rapidly-evolving Kinetis* MCU family.

This inspires me to do a bit more digging, and fiddling, and....

Well, the MCUs themselves are quite impressive, and, as I've noted, some of the low-end ones are seriously competing on price with low-end 8-bit MCUs.

The software support, though, is lagging a bit.  They're in process of moving from CodeWarrior (I've encountered other people using that, many years ago, on well-funded projects) to free Eclipse-based Kinetis Design Studio, and, well, things are in transition.  Real Soon Now, there's supposed to be KDS for Mac (it's currently on Windows and Linux, but one of my potential products is likely to have firmware developed for it by the sort of people who use iThings), and also key code ought to be migrated to the KDS/GNU environment, but that's Not There Yet, and importing example projects doesn't seem to work the way one would expect.

There was a hands-on KDS session at the Thursday thing, but, having been rather late in deciding I could attend at all, I was too late to get a seat in that session, and instead sat in on the sensor fusion session in the next room (which was interesting indeed, and I've downloaded those libraries, and sometime this spring I'll be trying to figure out how to use them).

Ah, well.  Another interesting development: some of the new chips (e.g., KL27Z series) come with a multi-interface bootloader in ROM, to allow installing firmware over USB, UART, I2C, or whatever, without at any time requiring use of a special-purpose debug/programming connector**.  Could be handy, and maybe for the project that was tentatively planned with a KL26Z, I should use a KL27Z instead (same size package, and, I believe, slightly more expensive but with more memory, and still price-competitive with an 8-bit solution when all's said and done).

 

Update: Now my FRDM-KL25Z board seems to have gotten frotzed.  I don't know if this happened as a result of my attempting to speak OpenSDA to it using KDS, or if it happened earlier, but now if I try to load an Mbed program I get the dreaded SWD ERROR, and, while there are various suggestions out there in Netland as to the cure for this, none of them actually appear to work.

The FRDM-K64F board does still work as an Mbed, and I'm not sure I want to sic KDS on it until I have a better idea what's going on.

As is typical In The Industry, the third-party tools (debugging pods and the like) are wildly expensive, at least the versions not subject to severe licensing restrictions (generally forbidding any manner of commercial use), and it looks like the firmware needed to make the vendor's own development tools work is also subject to awkward (and, presumably, widely ignored) restrictions.  So, it's not altogether clear whether one could, legally, sell knockoffs of the FRDM OpenSDA subsystem in pod form, at least in any usable state.  Which is really a shame, because (assuming it actually does work with KDS, if your target board hasn't gotten frotzed) it would make a nifty cheap programming pod, only a little pricier than one of the little USB AVR programmers and having actual debugging capability to boot.  (Though extending the pod design and its protocol to include control of target power would be a really nice thing for those of us who like to automate processes, hint hint.)

Update 2: Based on the debugging output when I run openocd manually, it looks like it's the target processor on the FRDM board that's gone bad... or maybe I messed up the SWD interface to it somehow, perhaps when I installed a set of headers on the board.

Anyway, for all I know, I've got a perfectly usable programming/debugging pod sitting there.  But if not... it looks like the "Multilink Universal" from P&E Micro might be about right, and the $200 price tag isn't all that painful as capital equipment goes.

 

* I still get this mixed up with Kinect and/or K'NEX.

** NXP has had this feature for years, but only supporting a UART interface, and with a somewhat poorly-considered convention for the use of modem-control signals.

Math bites again.

You know those cute little Li-Ion charger chips from Microchip?  The ones in the SOT23-5 package?

Very handy, should you have a USB-derived 5V supply handy and need to charge a Li-Ion cell.

Except...

If the cell is badly discharged...

And the source is 5V-or-so...

And the charge-rate pin is pulled HIGH...

That dinky chip is gonna be dissipating near a Watt.  Got good thermal connections?

Fortunately, the charge-rate control is driven by an MCU pin, not a strap, so preventing the next charger-chip burn-out was just a firmware change.

There's really no room for any serious thermal dissipation, anyway; everything else on that board is Efficient, and it gets crammed into a tiny (and thermally-insulated) space.

So...

Run the analog charger in low-current mode, and accept that charge time will be much greater than run time.  Continue this with the already-fabbed respin.

The next model may just have a PWM charger, especially if I go to an MCU that has a few fast PWM channels (so I can use dinky magnetics); I think I've found a way to use a KL26Z here, eventually, and save some components.  It'll definitely have low-battery warning & lockout, so advanced stages of discharge won't happen in normal use.

The $1 MCU strikes again

While out walkies this morning, and pondering a future product, I came up with a bit of an issue: since the product in question needs to support user-fiddled firmware installed via DFU, there has to be some way of getting back into the DFU firmware even if the installed operating firmware is totally b0rked.

There's no easy way to cycle power, and the only button is for user-interface purposes.

What I need is a reset circuit that recognizes a really long button press as a call for a hard reset of the main MCU, combined with a signal indicating that this is what happened, so that the bootloader will go into DFU mode rather than launching the (non-)operating firmware.

So, do I go looking for a reset chip that meets these criteria?

I do not.

I look for a cheap MCU in a tiny package.  Maybe an ATtiny13A, or maybe even an ATtiny4.

Not sure where I'll find a programming socket for these li'l puppies, though.  Hmmm... 3D printer, small PC board, and some ZEBRA strip?  Might be worth a try.

Update: If I go the tiny4 route, I need a SOT23-6 programming socket, and those aren't horribly expensive as capital equipment goes; see, e.g., here.  In-system programming is out, because space is at a premium and the programming header (even Tag-Connect style) takes up more space than the chip I'm trying to program.