LabNotes: Blue Smoke Edition

Last Updated: 2021-04-22 16:00:00 -0500

It’s been a while since I’ve done an update on PETI, the implemented-in-hardware virtual pet I’ve been designing, and that’s true for a very good reason: I’ve taken and killed it, stone dead.

Now, I don’t mean dead like Loom, the half-abandoned companion service for Tapestry, or dead like any of the projects that have flown the coop completely. I don’t even mean dead like “finished” projects such as python-enigma which are in holding waiting for things to go wrong and work to suddenly mean necessary again. I mean dead like a coaster - I have killed the development board version of the MSP430-FR5994 microcontroller that I’ve been using as the brain of the development article, and I did it trying to update a bitmap in the source code.

Okay, how?

Very early on in the Arcana Labs transition I had settled on the new logo and decided I wanted PETI to boot to that logo on splash instead of the old Kensho Security Labs logo - reason being was that I was going to be shooting new video and pictures of the device and adding some software functionality to it, so why not?

Anyway, this is easily achieved - you use the tool to drop a black and white png into an actual array of bytes, drop the bytes into memory as the array splash_bitmap in lib/display/splash.h, recompile and flash.

But then nothing booted, and I’m sorry to say that I don’t know why nothing booted, because two things are simultaneously true:

• There are changes in the code (versus what was previously flashed) beyond the splash array, as I had merged in changes Kosmogen had merged in. I believe these changes are perfectly valid.
• Simultaneously, two very stupid things happened:
  • In a fit of “new environment, who this” I plugged the development board into a pure-power slot on my USB hub that proves 5v3A power, which may or may not exceed the rated input for the board. (I’ve driven the board off of fast charge wall warts before, so I’m not sure that’s it).
  • At the same time, during debugging, while attempting to read the state of certain pins that drove the various functions on the LCD using a multimeter, I very foolishly bridged the 5v rail pin to several GPIO pins.

Unsurprisingly, the principal concern here is that I have several GPIO pins that seem to no longer be interested in working. I’ve even written a few short programs that do nothing other than drive those pins into the state I care about and hold them there, and nothing. It’s likely that I damaged the GPIO ports controlling those pins, but the upshot of the matter is that I can no longer use the current exemplar dev board to move forward.

What were you doing with 5V anywhere near the logic-level circuits anyway?

To be clear, the existence of the 5V rail is not necessary for the ongoing development of PETI, or a conscious decision that I made. The 5V rail is provided by the “EZ-FET”, an accessory section of the main launchpad dev board, and doesn’t normally interact with the MCU as it’s more juice than the component itself is rated to handle. It’s provided for the benefit of the various available accessory modules (via the booster pack standard) and for the developer. I’d have to double check, but I don’t think even the LCD module, the thirstiest component on the whole board, uses the 5V rail for anything.

The bad news is that there’s no way in the firmware to instruct the board to power down the 5V rail, nor any preset configuration pack I can send out with the source code that will disable it. The good news is that TI thought kindly of idiots like me, and for this (and many other) reasons the 5V rail can be disconnected via a jumper. Provided I don’t power that rail from any other source (like the power backplate), that’s a good enough solution.

Ordering New!

This proves to be an unfortunate setback. Of all my ongoing technical projects, PETI is the most entertaining, sits at the edge of what I’m trying to learn, and is probably the most interesting from external perspectives.

The good news is the source code still exists and (near as I can tell) there’s no faults in the LCD module itself. Even if there were, I have two spare exemplars of the LCD panel, meaning I can swap out the one on the booster pack if it’s somehow faulty.

This means I’ll be ordering a new LaunchPad kit from digikey, with the requisite delays for funding (earliest I can order it will be the end of next week, more likely the middle of May) and shipping. I also want to take the time to order some other necessary components and some of DigiKey’s new small-batch board prototypes, for the Controller Input Board.

If you’ve been following along you may know that I’ve already destroyed three of those boards - one through bad design and two others through bad solder work, fried components, and general tomfoolery. I’m hoping that by having the boards made with proper solder mask, and with the help of my new Hakko FX-880 “real boy” soldering iron, I can finally put together a version of the board that works.

If I do, look for some of the spare boards to suddenly appear online. One way or the other, this will probably be the last update on PETI until mid to late may, between shipping and funding times. Check instead for updates on other projects!

PETI is a major project intended to design and construct a virtual pet from Open Source Hardware and Software. If you would like to support the development of this, or any of the other projects I’m working on for Arcana Labs, and you wanted to show your support financially, your best avenue is via my Github Sponsors account or by making a one-time donation to Arcana Labs via Ko-Fi.com or through other avenues detailed here.