Silicon Valley Redneck

A session of slow-motion head-bashery winds down

On and off for the last few weeks (IMCFT, what with work being in Busy Mode), I've been trying to add support to AGROS for the USB device interface on the LPC2148 (and thence the LPC23xx and such).

Well, it's been frustrating.  The NXP documentation isn't very good, and the various sample code isn't set up to show just how the interface actually works.

Eventually, looking at Micrium's code, I figured out what I think is the last bit of magic: Set Address needs to have the command issued to the protocol engine once (so it takes effect on the next Setup packet), not twice (to take effect immediately), and the Set Address command needs to be ACKed with a zero-length packet.

Anyway, instead of seeing a half-second (or five-second) timeout and bus reset as with the various b0rked attempts, I'm now seeing a Get Configuration Descriptor command immediately after Set Address... and I'm not responding to it, because I haven't built a configuration descriptor yet.

Off to do some real work now (you know, the kind that pays the bills).  Once I get my USB driver working properly, I expect I'll post some nice sample code that shows just how the interface gets used.

Having USB device support in AGROS may come in handy for real work soon... toss in an ACM layer and a SCPI interpreter, and it looks like part of a line of quick'n'easy custom test equipment.

(Update: the USB class for something that speaks SCPI should of course be TMC, not ACM.  I think I have a copy of the TMC spec squirreled away somewhere... and it can't be any more perverse and incomprehensible than the ACM spec... can it?)

Field trips

A few weeks ago, I went on that one-day business trip to Inner Ruritania.  Seems a bit excessive, to spend all those hours on various planes just for one day of work at the customer site.

Well, now there's talk of sending me off to Klatch.  Way over there by the Mediterranean.  For a couple of hours.

I'm hoping I can solve the problem by some combination of e-mail and telephone.  It's gotta be something simple; the gizmo worked in the lab, and it worked in Upper Whatchacallistan, but send it off to Klatch and the computer can't talk to it.  Maybe it's the writing.  Do the serial ports run MSB-first in that part of the world?

And now for something completely different: back to FPGAs

In anticipation of one or more projects involving small-to-medium FPGAs, I'm setting out to learn more about the options.

I'd done some playing around with the Xilinx parts in the space of interest (Spartan 3E).  They look fairly promising.  The competition comes down to Altera (Cyclone II), and, now that I take a closer look, Actel (ProASIC3 / Igloo).

I have the Altera software installed on my office Windows box, but haven't done much with it.  For the application at hand, as it turns out, Altera is pretty much disqualified on grounds of not offering the right amount of logic in a small enough package without resorting to insanely fine-pitch design rules (there's about enough space for a 100-lead VQFP, but, for Altera, 144 leads seems to be the minimum).  [Update: The junior member of the plain-vanilla Cyclone family is available in a 100-lead TQFP; while it lacks some of the nifty features of Cyclone II/III and Spartan 3E, it seems quite adequate for the current task - which puts Altera back in the running.]  Given that I only need three inputs and one output for the application (plus five pins for the supervisory interface), even a 100-pin part is overkill in the I/O department.

I hadn't really been thinking of Actel, partly because I was remembering them from the mid-90s (antifuse FPGAs and a really expensive development environment) and partly because, the last time I'd looked at their newfangled flash-based parts, the development software was still out of my price range, unless I had a solid (and funded) requirement.

Well, now the development software is a free download, though it's even more obnoxiously encumbered than Altera's (node- and date-locked, requiring a new free license every year, in addition to the free version being Windows-only), and there's a cheap eval kit for the Igloo (the kit's called an Icicle, and Mouser has them for $108.something), so I got myself one of the kits, downloaded the software, and went through all the weirdness of getting a license.

(Setting up FlexLM manually is a nuisance.  Apart from anything else, the Windows environment-variable editor, like sundry other things in the Windows world, deals with potentially long lists of potentially long strings in a little bitty, non-resizeable window.  Talk about sucky UI design!)

Anyway: my first impression of Libero is that it'll get the job done, eventually, but that it's nowhere near as well designed as Xilinx's ISE.  It appears that each stage of the build process is meant to be invoked manually (no "make" button), and I'm not finding a nice summary of resources available vs. resources used (which is right there on the front page of an ISE project).

Determining resource usage is going to be important in evaluating parts for a given application... maybe I'll find the information I need, hidden somewhere, when I get around to wading through the manual.

The time-locked license may be an issue for the client, too; the prospective product is meant to have a 20-year support cycle, and having the ability to maintain a stable development environment is important.  This may yet push the whole thing back to the Xilinx platform.

Apart from the development-software issues, the ProASIC3 does have a certain amount of promise for the application at hand: it seems to be available from stock in the right combination of size, package, and temperature range, at a decently low price; the instant-on characteristic is a good thing; and the 1K bits of user flash could prove useful for storing model-specific parameters, leaving the actual Verilog program invariant (I'd been planning to use an external serial memory for that purpose, but the ProASIC3 could be a one-chip solution).

Well, that went smoothly. Mostly.

Up two hours earlier than usual, deal with essential morning stuff, leave the house about the time I normally start to think about waking up, drive to San Francisco Airport in plenty of time for my flight to Ruritania International (actual destination omitted to protect the client's identity), arrive on time, meet up with the boss's brother, proceed to a small town in Inner Ruritania, find the small unmarked building we're looking for, get the tour, have a productive discussion with the owners, return to Ruritania International about 40 minutes before flight time, check in, have a few minutes for reading before boarding commences, get on plane, arrive at Regional Hub on schedule, find the gate for the connecting flight, grab a slice of overpriced airport pizza, dig out the laptop and hook it up to the cellphone (Ruritania International had banners advertising free Wi-Fi, but I didn't have time to check it out; Regional Hub has Boingo, which redirects to what I assume is meant to be a show-me-your-credit-card page, but it was broken, at least with Konqueror), make a quick scan of e-mail and news, return to reading the book I'd brought, board the third plane of the day, return to SFO about 15 minutes early, get home about 1-2 hours past normal bedtime.

Whew!

Three planes in a row running on time, with no sitting around burning fuel while waiting for a turn to take off, and no problems with security.  (Flight #1 was Skywest as United; #2, Skywest as Delta; #3, Delta.)

The seats are still made for people without shoulders, though.  Luckily, on flights #2 and 3, the seat next to me was vacant.

Oh, and the windows on the CRJ200 are evidently meant for children, or at least for someone a lot shorter than I am (and I'm not exactly uncommonly tall).

I was a little confused to find that the flight from RI to RH had two numbers, with the same digits but not in the same order; the sign was showing both, but the number they announced wasn't the one on my boarding pass... but, it was at the right time, from the right gate, to the right destination, with the right airline, they let me get on, and there wasn't somebody else in my seat, so I guess it must have been the right plane.

The real confusion: SFO.  The signage there sucks like a bilge pump.  I wanted to park in short-term parking for Domestic Terminal 3, which I think should have been Garage F... but following the signs for "Short-term parking" got me dumped in Garage A, with an option for Garage G.  OK, so I park in A, and head for the terminal.  Now I'm in International Terminal A, and there don't seem to be any signs directing me to the domestic terminals.  So, I wander around, and eventually find the "AirTrain" thingie (not to be confused with AirTran, for which there were also signs), which goes around in circles and eventually delivers me to Terminal 3.  Getting off the plane, I'm confused again, and it take me quite a while to find the AirTrain.  Then, exiting the garage, I attempt to follow the signs for the freeways, discover that signs are sparse and often lacking arrows at complex intersections, and find myself driving a long way past a cargo terminal with no reassurance that the road eventually leads to the freeway, which I can see just over there on the left, if only my car had a teleport button.  Yes, the road did connect to the freeway, but having some clear signs along the way would have been nice.

Well, I don't in fact seem to be sleeping in this morning... got a bunch of stuff to write up for work.  It was a highly educational meeting.  Apart from the work stuff, I established pretty well that I don't have any latent vegetarian tendencies... and, surprise surprise, that NIMBYs can be a wildly dishonest bunch.  (Elaboration may follow, with identifying details suitably scrubbed to protect the client from militant NIMBYs and other radical elements.)

Putting the Iggle back to work, hooray!

I'd been kvetching about how some recent update to something on my Debian-unstable workstation had caused EAGLE (PCB layout / schematic-capture program from Cadsoft) to be terribly slow at doing anything window-related.  Window redisplaying and resizing were terribly sluggish.

Well, I'm actually needing to use EAGLE for real work, and the persistent slowness was getting to be enough of an obstacle that I did some further digging.

It's not Lenny, and it's not x.org (someone's suggested change to xorg.conf for a similar-sounding, but not EAGLE-specific, problem had no perceptible effect).  It's the Nvidia closed-source driver (173.14.09), which I believe I updated from an older, not-having-this-problem version to accommodate a new kernel version.

This discussion thread turns up the solution:

Big part of the problem is that nvidia driver is unable to set automatically this 'InitialPixmapPlacement' (whatever that means) to right value for the current system. It makes a HUGE difference setting that right for your system. At home on 8800 right value was 0 if I'm not mistaken, here at work on 6200 it is 2 and on my colleague's 6200 it is 0. And nvidia's setting is ALWAYS 1. So the driver just don't know what to set and they just hard set it to 1. So if You want to experiment try this 'nvidia-settings -a InitialPixmapPlacement=0 to 4' and running gtkperf after each setting to check if speed changes. Mine went from 60 sec total to 7 sec !!! (that of course depend much on the theme and fastest one is 'ThinIce'). And of course it SHOULD NOT BE USER'S problem to test which setting is best for their system and that default setting to be 90% slower than best making the whole system worthless ...

Well.

Not having gtkperf installed, I tried the nvidia-settings incantation with the suggested values, trying EAGLE after each.

A value of 2 turns out to be right for my system; EAGLE is back to its old zippy self.  A value of 4 might perhaps have been even a tad faster, but the results were wrong, making it rather non-useful.

The next suggested solution works too.  Set InitialPixmapPlacement back to 1, go into the menu editor, and change the invocation of EAGLE from

nice /opt/eagle/bin/eagle

to

XLIB_SKIP_ARGB_VISUALS=1 nice /opt/eagle/bin/eagle

(Assuming, of course, that EAGLE lives in /opt/eagle, and that you like to run it niced so autoroutes don't drag your web surfing down.)  This also seems to work fine.  Don't ask me why, nor what that xlib environment variable is doing.

Bloody enlightened European...

I'd forgotten what a pain European standards can be....

Y'know those Eurocard-type connectors?  Used for VMEbus and suchlike?  The DIN41612 family?

Well.

Once again, I need to incorporate such things into a trivial design.  We have two cards mating edge-to-edge, so there are two right-angle connectors involved.

The male, it appears, is Style C, and the female, Style R.

A board already designed by the client has a right-angle female connector on it.

I check the pinout against a drawing from ERNI.

Oops!  The client has reversed the numbering!  They've got A1 where A32 should be!

After much futzing around, and contemplating in detail the drawings from both ERNI and Tyco, I come to a conclusion:

The standard is wrong.

Whatever sitzpinkler wrote the standard numbered the contacts from right to left, as seen from the contact end of the connector.

On both the plug and the receptacle.  Full gender equality, you see.

Only, y'see, when the connectors mate, as is their function in life, one of them necessarily gets turned around, owing to their inflexible anatomy.  They gotta be facing each other, or it just doesn't work.

So, e.g., pin A1 on the plug gets connected to pin A32 on the receptacle.

Makes bus documentation kinda interesting.  Ya gotta specify whether the numbering in use is for the plug or for the receptacle.

Anyway, there's half an afternoon shot.

Another half-baked design becomes a standard

Continuing with AGROS development, I'm now getting around to supporting the SSP (synchronous serial port) on the LPC21xx, having used the SPI port for quite some time now.

The spec for the SSP is a tad confusing, but I've got it pretty well deciphered now.  It's the ARM SSP PrimeCell, PL022, except that the LPC21xx version lacks the DMA control register... something about not having a DMA controller to connect it to.

So now I've got the official ARM PL022 spec in front of me, and there are some definite crocks graven in stone:

First, though not very important, there's the business of breaking the clock division into an 8-bit prescale register and an 8-bit divider register.  Why not just have one, 16-bit register?  I suspect evolutionary heritage here, as the control register is also broken into two 8-bit registers, with the divider register occupying the high byte of the first control register's address.

Then there's the SSEL signal.  In SPI mode, SSEL is automatically generated; it goes low at the beginning of a frame (frame = one write to the data register = 4 to 16 bits), and high again at the end of the frame.

Well, that's fine if you're talking to a really simple peripheral, like an LED driver... and there's only one of it... and it's not more than 16 bits long.  Typically, though, you need to clock out more than 16 bits - consider, for example, an SPI memory device, which wants a command byte followed by a whole bunch of data bytes, all under a single chip select.  This means you're back to manual control of SSEL.

The need for manual control of SSEL, whether for long frames or for some other reason like supporting multiple slave devices, leads us to the third problem: the completion interrupt, or, rather, the lack thereof.  There are four interrupt conditions available: receiver overrun, transmit FIFO half empty, receive FIFO half full, and receiver timeout.

Now, can anyone familiar with SPI tell me what's wrong with that choice of interrupt conditions?  No, not all at once!  Yes, that's right.  Transmit and receive are inherently simultaneous conditions, so having separate transmit and receive interrupts makes little sense.  Having an interrupt for receiver overrun makes even less sense.  Then there's the receive timeout... er... I suppose that might make sense in slave mode, but, since this cell is basically used in microcontrollers and likely to be the master, the whole "timeout" concept isn't especially useful.

What I really want, so I can deassert SSEL and pull the next request out of the queue, is a "done" interrupt.  There's a "busy" bit over in the status register, but no way to get an interrupt based on its having gone inactive.  So, I guess I'm stuck with waiting 32 bit times for the receive timeout interrupt to happen so I can check the status register, find BUSY to be false, and deassert SSEL.  Foo.

Decisions, decisions...

Pondering likely near-future applications of this FPGA stuff I'm learning, I note that they mostly require I-temp devices (-40 to +85C or better).

Digi-Key only carries suitable-sized Spartan 3E parts in C-temp, but, somewhere in my pile of notes is a pointer to a distributor that stocks I-temp parts in the right package, and sells them in onesies.

Of course, I could always look at the competition, i.e., the Zyklon B Cylon:TNG Cyclone II family.  Available from stock in what looks like the right complexity, the right temperature range, and a possibly suitable package, and the price is right.  The logic looks comparable, and, while there aren't as many PLLs, the ones it does have look a bit better suited to my purposes than the Spartan ones.

There's a free-download version of the toolkit, too.  Annoyances: (1) it's Windows-only, and (2) it's node-locked, requiring a license that's tied to a particular Ethernet MAC address.  Xilinx is much friendlier here, with a Windows/Linux toolkit that's downloadable with minimum rigmarole.

Then there's the issue of configuration memory.  The Altera FPGAs have appealing prices, but... $13 for the cheapest configuration PROM?  Eek!  Well, it appears that standard (cheap) SPI flash will work, but that's not stated in the Cyclone II datasheet (score another point for Xilinx, with detailed info on third-party configuration memory in the datasheet).

Ah, well.  Actual decision time is a ways off, none of the actual projects having been sold to clients yet.  So, there's time to ponder, and incentive to code my collection of little utilities in vendor-independent behavioral VHDL as much as practical (shoving things like clock multipliers into a vendor ghetto).  At some point, I'll try building a test design for both Xilinx and Altera targets, and see how the logic utilization compares.

Then there's the matter of an extended-temperature microcontroller.  At this point, the LPC2194 looks most promising.  Apart from being a close relative of the parts I'm already using, it has decent amounts of flash and RAM.  I just took a look at the ADuC7128: extended temperature range, check; decent set of base peripherals, check; enough memory... well, maybe the reason ADuC floats is that it's light on RAM.  I can live with the 126K of flash, but 8K of RAM would be barely enough for the existing application, and I can see future communication requirements eating quite a bit more.  Well, for the moment, the regular I-temp (-40 to +85C) LPC2000-series parts are fine, and perhaps stretching the top of the range to +100 or beyond can wait a while yet.

Aha! Gotcha, you pesky bug!

So, that bug I was trying to track down yesterday?  The whole reason for hooking up the JTAG pod, and on and....

Well.

I hadn't quite ported the I²C interface driver from the old configuration system (data structures in source file) to the new system (XML in source file; data structures filled in by configuration program).

The device private data structure for I²C extends the standard structure by one word, and the configuration program didn't know about this.  See the result: on a "bus successfully claimed" interrupt, the retry limit gets set to 10, clobbering whatever comes just after the private data structure.  Which is the first word of another data structure, which happens to belong to the system timer.  The first word is a pointer to a list of registered event handlers.

So, what do you suppose happens the next time the clock ticks?

And it's not like tracing a data abort trap back to its origin is especially easy on the ARM architecture.  This took all morning.  (Well, from 7 to 9:15, modulo breakfast, more or less.)

And the new I/O chaining mechanism is in place, and works, and eliminates the need (at least in this case) for locking the bus device before queuing up the address- & data-phase requests.

(Ah.  And the reason the abort was postponed if I tossed some kprintf()s into the I²C interrupt handler would be that, as long as the next interrupt was pending before the handler exited, the timer interrupt wouldn't get handled for that much longer.  Likewise for setting breakpoints in the handler: the bus operation would finish and the next request be pending.)

Well, that was a frustrating afternoon.

After making a long-awaited group of changes to the AGROS configuration program - thereby enabling use of optional protocol layers, external devices on the I²C bus, etc. - I made what should have been a fairly straightforward change to the I²C driver, and started testing.

Oops.  Wedgie!  The "START completed" interrupt happens, I send out the address byte, and nothing happens ever again.

Time to hook up the JTAG debugging pod.

Doubleplusoops.  The pod doesn't work.  I get yer basic JTAG communication failure, with, generally, RTCK not happening and a device ID of zero coming back (i.e., RTCK and TDO are both sitting low).

Erasing flash and maybe loading an old binary for a different gadget makes the JTAG work.  I've deconfigured the watchdog, so that's not it....

Much poking around, some Googlery, and here's the key:

One oddity about FreeRTOS on these boards is that it seems to disable the JTAG debugging interface while FreeRTOS is executing. In particular, while FreeRTOS is running, when you start OpenOCD, it gets a JTAG communication failure. I found that if you un plug power, set the ICSP dip swich #1 to on, plug in power again the re-program and turn off the dip switch again it will work. This is caused by the CPU going into low power/sleep mode in the FreeRTOS idle loop. You can stop that from happening by commenting out that line of code in the idle call.

I'm not using FreeRTOS, obviously (if I were, I wouldn't be debugging AGROS, now would I?), but I am calling a machine-specific low-power sleep function in the idle task... which, as noted, causes JTAG to go funny.  Obviously, I need to add a configuration option to disable low-power sleep for debugging purposes.

The I²C still isn't working, but now at least I can use the JTAG pod to debug it....

Update: funny, the request is there... the enable is there... but the next interrupt never happens.  D'OH!  I forgot to call irq_done() at the end of the service routine!  That must have been present in the earlier version, but somehow it got lost.