Orthrus

I managed to figure out how to do field firmware updates over USB. Here's the process:

1. Fetch the micro SAM-BA source from GitHub. Compile it. It should work fine on Linux or MacOS X.
2. Short the erase jumper and plug in a USB cable to apply power. Unplug the cable and unshort the erase jumper. Plug the USB cable back in.
3. The three LEDs may be glowing very faintly at this point (the default GPIO config is pulled-up). You should see a CDC device (a virtual serial port). Take note of the device name.
4. Run these commands (setting GPNVM bit 0 is the "security" bit that will lock out all debug interfaces - do it only as an absolute last step or you will have to re-erase the chip and start over):

   usamba [port] write Orthrus.bin 0
   usamba [port] gpnvm set 1
   usamba [port] gpnvm clear 8
   usamba [port] gpnvm clear 7 
   usamba [port] gpnvm set 0

5. Unplug and re-plug the USB cable. You should see Orthrus running the new firmware.

Note that because of this, it is imperative that you insure that access to the ERASE jumper is prevented to insure that rogue firmware cannot be loaded. The best way to do this is to embed Orthrus in a case to which you can apply tamper-evident seals.

Over the course of a couple evenings, I got every part of the system working... except USB.

That means the card I/O system works, the user interface (which is to say, the lights and button) functions properly and the encryption system interoperates with the previous versions correctly. I've even managed to perform a simple preliminary performance test which seems to show that it's able to read at a rate of something around 1 MB/sec - not quite 10 times faster than the previous version.

USB is the current sticking point. The USB interface remains completely and totally inert. I suspect that the hardware functions properly, because if I short the erase jumper, SAM-BA brings up a CDC device that works properly.

I got Atmel Studio 7 generating code correctly after a brief struggle. It turns out there are some bugs in the current version, but you can work around them by adding some code to the Reset_Handler() method and manually setting the GPNVM bits rather than using the "Boot from" dropdown menu (which doesn't seem to work). That done, I have exerted control over the buttons, LEDs and card detect pins. Next is taking control of the HSMCI interface and crypto subsystems. The ability to actually interactively debug this stuff (rather than using tombstone debugging) is kind of amazing - almost worth having to run Windows for. Almost. :)

Real Life^tm is going to get in the way for the next few days, however. But I really want to get the firmware done by Halloween October. We'll see.

Oh, as before, the firmware will be open source, under GPL v2. There will be portions that remain under the original BSD license (since ASF is Atmel's code), but my stuff will be GPLed.

I figured out what was wrong with the v3 prototype. It turns out that the case of the SAMS70N19 has two "divots" in the top near two of the corners. One of them is very large, the other one somewhat smaller. Turns out, the big one isn't near pin 1. The smaller one is, along with a chamfered corner. Flipping the chip around the right way allowed it not only to enumerate on the bus, but also to be probed with SWD from my AtmelICE in Atmel Studio.

The only other interesting discovery was that the VBG bias resistor was supposed to be 5.62 kΩ instead of 56 kΩ. Fortunately, that doesn't require changing anything on the board.

The only other thing that's less than perfect about the prototype is that the fine pin pitch of the LQFP package inevitably requires rework after the oven to remove bridging.

So, nothing to do now but get on with the firmware.

I built the first v3.0 prototype, and unfortunately, it doesn't seem to work.

All of the power supply voltages seem correct, and swapping the controller out for a new one didn't change the behavior. It doesn't enumerate properly on the USB bus, as the documentation seems to imply it should, and I just don't think it's booting up properly at all.

The problem now is that I really am not sure where to go next.

Now that the v3 hardware is in process, it's time to think about the firmware.

I'm going to hold my nose and use Atmel's IDE under Windows just because it seems to be the path of least resistance (and I'm in a bit of a hurry). The hope is that they have some sample code for a USB mass storage device, and some more sample code for an SD card reader. If the two can be stitched together, then the hope is that it will be relatively simple to adapt the A/B switching, encryption and the rest of the UI from the v2 LUFA code.

To load the firmware, there are two options. One is the SWD interface on the board. I believe it should, in principle, be possible to attach the ribbon cable from my ATMelICE's SAM port to the board and use that for programming. But in addition to that, the datasheet seems to indicate that the blank chip will come up on the USB bus and present a CDC interface over which programming can take place. In addition to that, I've added an ERASE jumper to the board that hopefully will return the chip to this same state, allowing pure USB programming to be the preferred method. This would allow for field firmware updates more easily - the user would jumper ERASE and connect power briefly, then remove the jumper connect USB and run some sort of programming software to load the new code in.

For proper security, end users will want to seal Orthrus inside of a case of some sort. The purpose of the case will be to prevent access to the SWD interface (the fact that there's an interface on the board layout doesn't imply that the lack of one would make SWD impossible to access without it). A laser-cut acrylic layer case that screws together along with a pair of tamper-evident adhesive seals would be sufficient to allow access only to the USB port, the two SD card slots and the button. With access only to those ports, it will be much more difficult to implant rogue firmware (I won't say impossible because I can't know that for certain).

I've uploaded the preliminary schematic (EAGLE & PDF) and board file for Orthrus v3.0.

This version is the full deal. It's got an ATSAMS70N19 in the TQFP form factor and is set up for high-speed USB. The HSMCI interface is set up for A/B switching with the bus switch ICs, with both cards disconnected when card power is turned off. Since the S70 has a built-in TRNG, the entropy generator and its power supply are no longer present. The entire thing consists of the controller and its support systems, the two cards and the HSMCI multiplexer, the button, the three LEDs and the 3.3v buck converter to power the whole thing.

I'm going to see if I can get some ARM experts to chime in on the design and layout before I order it. I really want to get the hardware as close to perfect as I can the first time out. Assuming it doesn't spectacularly fail (and assuming I can get the firmware written in time), that version will be submitted to the judges for the Hackaday Prize. 

UPDATE:

After getting some design feedback (thank you very much, @cj), I've updated the v3.0 design. It's been uploaded, but since the files have the same name, I'm not sure Hackaday.io has it figured out. It may need time to update the caches or something.

I've gotten a few sales in the Tindie store, but I've recently got a spate of requests by folks for shipping rates to foreign countries. Unfortunately - as it says on the store page - I cannot export Orthrus from the United States. I've started down the road of asking for an export license from the Commerce department, but that has basically gone nowhere. It wouldn't surprise me a bit if they eventually denied it outright.

Orthrus is open source firmware, but it relies on hardware cryptographic acceleration, which means that the usual exemptions for open-source don't apply. Even if they did apply to the firmware, I'd be unable to export programmed units because they're not pure software. Of course, all of those distinctions are moot because the current hardware - even with no firmware - requires an export license because of the cryptographic hardware.

Today I built one of the test boards I made with the bus multiplex chip and the current Orthrus design (with the XMega32U4), and modified the firmware as appropriate. The result works just fine. This shows that at least the SPI bus can be moved back and forth between two cards in this way. This version was just a test - I ripped the TRNG circuitry off the board, so it's not a full implementation (it wouldn't be able to securely initialize a new pair), but it does mount existing pairs just fine.

The next step will be to complete the new v3 design and get the boards ordered. There's nothing really holding that back. It's just arduous to add all the bypass components the datasheet calls for and route the circuitry. Since it's Labor Day weekend here in the U.S., I think labor will be my calling.

It appears that I may have a good solution for the problem of two SD cards on a single interface. The QS3VH257PAG8 is a 4 x 2:1 bidirectional bus multiplexer. It essentially is an on-off switch for signals going in either direction, and this particular chip's configuration has two switches in parallel with one side wired to a common pin and configured so that a selector input choses one or the other. Since this chip is a 4x, it would take 2 chips to handle the 6 pins on an SD card. Each chip also has an absolute enable, which we can tie to the GPIO pin from the controller that turns the card power on. The selector lines will go to another GPIO pin that will act as an A/!B line. When the select and enable lines are stable, the maximum propagation delay through the chip is 200 ps, which is mighty small (25 MHz is 40 ns), so I have fairly high hopes it won't get in the way.

Edit:

I've designed an experimental board with the v2.0 circuit (without the RNG) and one of these chips in place of the shared SPI bus. The SD initialization code will need a bit of adjustment, as the two separate !CS lines are replaced by an A/!B pin and a shared !CS line. But if it works, it will give me some measure of confidence that this will be an acceptable way to mux the cards on the next variant once the design with the SAME70 is ready. See? Knocking away the question marks a few at a time instead of all at once.