SDHC USB Bootloader and Logging Firmware work!

I have the old Logomatic 2.3 working with the new SDHC USB bootloader. At first, FAT32 was not enabled. because the mass storage part doesn't even need a filesystem driver, the host takes care of it. However, In order to find and install FW.SFE, the bootloader needs FAT32 however, so this version has it.

Also, the old Logomatic firmware has been updated the minimum amount to use SDHC and FAT32.

All of this works for me, and generates log files, but it sometimes takes a LONG time to mount over USB (sometimes a minute or more).

So now I have put my code where my mouth is.
USB_SDHC_Bootloader.zip
Logomatic_SDHC_FAT32.zip

More on SDHC

So here's the problem. There are in fact two SD card drivers in the Logomatic firmware. Hey, by the engineering method, anything that works is good, and the Logomatic code works, but it's not great code. There are entire sections that are included but not used, like the USB driver in the main logging firmware. Now we have two pieces of code to do the same thing -- access the SD card. There is Roland Riegel's code used by rootdir.c and used by both the bootloader and main code to read and write the card, and there is the code used by the USB driver, which is entirely separate and entirely unready to do SDHC.

So, I am going to update the USB driver to use Roland's code. This just means mapping what the code is doing now to the various parts of sd_raw.c . Piece of cake, probably. We'll see.

Anyway, once this is done, I'll post a message about it on the Sparkfun forums, direct them here, and get literally some readers on this blog, rather than just myself like I get now.

No bragging until I can put my code where my mouth is.

By the way: I am doing all of this development on the Loginator 1.1, so the SD card slot and USB port work. Yay for me!

Loginator and SDHC progress

1. All purely computing parts of the Loginator have now been tested. The power supply, USB, SD card slot, RGB light, and BOOT button all work. The charger circuit itself works, but I installed the LED backwards.
2. None of the analog parts have been tested. The current sensor was originally too hot to touch when the board was on. I tried to remove it, but in the process of hitting it with the soldering iron I must have fixed it, either that or it is burned out completely. Won't know until I test the analog part. I also realized that I should have gotten the 100V/V part instead of the 20V/V part. This is fixable without any board modification.
3. I may have made a foolish decision in relation to the RGB light: you can't run the lights as lights at the same time as you use the UART ports. Honestly it's not my fault. There are six PWM pins, but four of them are shared with TX and RX on the two UART ports, one is shared with the chip select pin for the card reader, and one is AD6. Right now I just use the blue and green lights, which overlap UART0. The red one overlaps TX on UART1.
4. I put into the Logomatic main firmware code some compiler switches so that it can be switched to be Loginator with one switch. This controls where the code looks for the lights and STOP button. With this switch set, the Sparkfun firmware now runs on the Loginator. It is even bug compatible - the first log file is LOF01.TXT. Next is to get Logomatic Kwan adapted the same way.
5. The SPI port with the SD card on it works, but I haven't tested the other SPI port or either of the I2C ports. I made a silly mistake and wired a pullup resistor to SCK1 (SPI) instead of SCL1 (I2C). I2C0 is fine, but the 11dof port uses SPI1 and I2C1, both of the affected busses. This is fixable with a green wire and a cut trace. The board modification does not require a new stencil.
6. I jumped in face first with the SDHC patch and got burned. The Logomatic code now no longer creates log files. I have seen through the serial port that the code is reading the configuration file, but cannot or will not write the log file. What I will do is back out the FAT32 part and just use the new SDHC part, to start with. Once the Logomatic with SDHC works, I will update the bootloader similarly, then actually try it with an SDHC card.
7. I have been looking at the LPC2468 chip. It has a purpose built SD port, DMA everywhere, USB, Ethernet if I ever wanted to use that, lots of cool new features. It's even cheaper than the LPC2148. The only problem is that it is a 208 pin chip, and I don't know if I will ever be able to solder down such a chip. Also its 28x28mm, so it may not even fit in the Logomatic board footprint. DMA is cool because it is like an arbitrary-length FIFO for every device, anywhere in memory I want it.

SDHC - How do we test it?

1. Compile original Logomatic firmware and install it, and see that it runs on a fat16 SD
2. Compile original USB bootloader, install it, see that it runs on fat16 SD
3. Modify Logomatic firmware to use new library, see that it still runs on fat16 SD
4. Modify USB bootloader, install it, see that it runs on fat16 SD
5. Put an SDHC card in, see if it is visible over USB
6. Put a blink firmware on the SDHC and see if it is installed
7. Put Logomatic firmware back on the SDHC, install it, see if it runs
8. Success!

Logomatic and Loginator with SDHC and Fat32

Your Logomatic probably doesn't need fat32. It probably doesn't need more than 2GiB files or 2GiB of storage total. It probably doesn't have the battery life to support writing 2GiB.

But microSD cards that aren't SDHC are becoming hard to find. The hardware needed to interface SDHC is no different than normal microSD. It's just software. Your Logomatic (or mine for that matter, constructed in 2009) just needs a mind transplant, a simple firmware upgrade. Well, not so simple, because that firmware doesn't exist yet.

That's where I come in. I am back in the Logomatic (and Loginator, which is substantially the same) business, for the while until my attention drifts elsewhere. Hope I finish, or hope that you or someone reading can pick up where I leave off.

So, a word about the SD card software currently in the Logomatic and USB bootloader code. You can find the USB bootloader code on the Sparkfun USB bootloader tutorial, and the Logomatic firmware also on the Sparkfun site.

Remember that both of these programs are installed at the factory on each Logomatic, so you already have these in compiled form. They share no memory, but have much identical code. See, the USB bootloader needs to access the SD card, both to do the USB mass storage thing, and to check if your firmware FW.SFE file is there and read it and install it if necessary. It also has a USB driver to convert USB signals into microSD commands and vice versa. The Logomatic main firmware needs much of the same code (except for the USB part) to read its configuration files and write data to the card.

This code comes in the form of some .c files, along with supporting .h files. These files were the work of Roland Riegel, and through the magic of open source, we get to read and modify them as we see fit. As it turns out, Roland has already modified his code to handle SDHC cards, and as a logical extension, the fat32 file system. So what is left to us? Modifying this code to handle the LPC2148 chip instead of the ATmega32 that he uses. Yes, I just saw you Arduino users' ears perk up. Sorry to dissapoint, but I am not going to do anything with either Arduino or ATmega, but that doesn't mean that you can't.

So, here is how the sd-reader (as Roland calls his whole work) is structured. At its lowest level is sd_raw.c . This file is used to control the card and read and write blocks of it. This code can be used directly if you want to use the sd card without worrying about unnecessary bloatware like file systems. It also is used by the USB mass memory driver. In this case, the USB host (probably your desktop computer) sees the USB device (the Logomatic and its SD card) as a featureless sea of blocks. The USB wire protocol just concerns itself with reading and writing those blocks, along with such bookkeeping things as determining how many blocks there are. The USB driver in the LPC2148 mostly just interprets USB commands and uses the sd_raw library to fulfill these commands. The LPC2148 in this case doesn't care about filesystems. The host sees the raw blocks and it interprets them as a filesystem. In principle, this allows the host to use any filesystem it wants, without the Logomatic caring. If you wanted to, you could format the card in a Logomatic as fat16, fat32, ext4, whatever Mac uses this week, etc. We will see why this is not a good idea later.

On top of this low-level interface, we have

• fat16.c, which knows about directories and files 
• rootdir.c which sits on top of fat16 and makes it so that your code doesn't have to worry about directories 
• partition.c which reads the partition table on the sd card and finds the partitions so that fat16 knows where to start.

The file reader in the USB bootloader and the file reader and writer in the Logomatic main firmware are both based upon this code. This code specifically assumes that the card is formatted as FAT, FAT16 to be specific. If your card is not formatted as FAT16, then the USB bootloader will not be able to find and load FW.SFE. In this case, the code is running free, without the guidance of the USB host to interpret things. It needs to interpret the data on the card as a filesystem all by itself. If the filesystem is not FAT16, fat16.c will detect and complain about this, and the files will not be read nor written.

So how are we going to use all this code which was written for an ATmega on an LPC? That's the magic of C code and compilers. 99+% of the C code in these files will compile without change. This includes all of fat16, rootdir, and partition. These use sd_raw. Sd_raw in turn is about 99% portable as well. It knows the SD wire protocol, and how it sits on top o the SPI protocol. All it needs to know about the hardware is what registers control the SPI protocol and how to use them. This knowledge is isolated into a couple of functions, and we need only change these functions to port the code from ATmega to LPC. Almost all this code is already well-isolated, there is just one bit left that can be broken out.

More on this as I actually do it...