Bootload from USB key or SD/MMC card?

[Guest]

So I am working on a project where we want field updates (who doesn't)! The easiest option will be to send out a USB key or SD/MMC card. USB keys seem to be everywhere so that is what I am leaning towards. My options seem to be:

1) PIC with UART and VNC1L acting as host
2) Wait for USB OTG PIC32 later this month and give it a whirl
3) PIC with SPI to SD/MMC

With any of these options, I assume that I need to use some sort of FAT16/32 code to decode what is on any of the external devices (assuming they get loaded with code from a Windows computer). Is this true? The VNC1L seems somewhat buggy from what I have read. Option 2 seems nice if they provide some source to get started. Option 3 seems to be tried and true around here. Any other thoughts or suggestions? I guess my only questions is that regardless of path, I need to have FAT decoding within the bootloader? Thanks!

[jma_1]

Check out the TEAclipper for field programming a PIC. The product was featured in a Circuit Cellar magazine article a few months back. I like the idea of encryption as well as time limits / limited # of installs.

http://www.flexipanel.com/TEAclipper.htm

A future product from Microchip may be problematic. Exactly when the device and details are available is always a question. Deadlines are forever changing. I will probably try this option myself, but after some of the bugs are cleared up. I also do not want to purchase another compiler at the moment.

A dual purpose, host / slave, OTG chip might be quicker and more simple to debug. The learning curve with a new processor is always interesting, especially if you are used to the PIC architecture and now are basically switching to MIPS with the PIC32. Check out the USB chips from Philips semiconductor (new name?) and Cypress.

[Ttelmah]

The simplest is option 3. Even better, you can avoid the need for FAT decoding. If you make your program on the PC, reformat the SD card, and write a dummy file, that fills the entire card, you know that this starts right after the MBR, and directory entries. You can do simple direct reads of this, without getting involved in the size of a FAT library.
Write your code into this file, and away you go.
Add mild encryption if you want.
It is down to timescales. This could be running in a very few days. The other options may be nicer, but is the cost justified?.

Best Wishes

[ckielstra]

My first reaction is that PIC and USB-host functionality don't match. The PIC processor is popular because it is so cheap and targeted to products where every cent counts. Adding a $8.50 VCN1L or $32 TeaClipper gets the implementation done fast but then you have started with the wrong processor in the first place.

The USB OTG PIC32 sounds nice but is only available in several months and knowing Microchip there will be bugs in the first stepping. Can you afford to wait a year for a stable product? Besides, this chip is named PIC32 but has (almost) no architectural resemblance to the PIC16/18. You will have to learn the totally different MIPS architecture. When considering a new architecture you might as well have a look at the many competing ARM based processors. How about running Linux as your OS? There are many US$10 ARM processors which can do this. You will have your USB & FAT drivers available and tested for free...

For a cheap and easy to implement PIC solution I agree with Ttelmah, option 3 is the way to go.

Another way to avoid the FAT implementation is by creating a PC program that writes the raw firmware to the SD card in your own sequential format.

[ckielstra]

I'd like to suggest another option:
5) The PIC connects as a USB-slave to the user's PC.
PIC processors with USB slave controller are available or this functionality can be added by a relative cheap external chip (FTDI's FT232R and others). To the PC this looks just like an external connected serial device. Well tested and easy to implement with many examples present.

I especially like the fact that this new connector is not only there for software updates but can be used for other purposes as well: debugging, (log)data dumping, configuration, etc.

[jma_1]

I agree with both ckielstra and Ttelmah concerning option 3.

Option 5 is a nice option which I presently use, PIC18F & FTDI chip. This is a simple and clean option which works well considering most newer laptops these days do not have serial ports.

If you go with the virtual serial port option stand alone chip, consider both the FTDI and silicon labs. Both offer a chip with a built in eeprom, oscillator, etc. which will minimize the external components you need.

Which ever way you decide, try to answer the questions:
how expensive?
how much time for development?
security?
ease of use?

Hopefully they will help you decide which way is the best for your application.
Cheers,
JMA

[SimpleAsPossible]

I recently hacked a VDIP1 module onto a CCS development board. It ended up working OK. I wasn't too happy about the issues related to setting the baud rate higher than the default -- I went to either 115200 or 230400, I forget which. Make sure you use the hardware handshaking. I also ended up having to turn off the power to the module to reset it properly when I needed to clear out an unfinished read on a huge file. It was pretty easy to move around the file system and read files (I didn't write any except during some of the early testing).

After I got it working, I was extremely satisfied with being able to update the configuration and data files on the fly with the USB drive. The system controlled some hardware and drove a signal as it was read from a file. The actual code was pretty Simple, and the main development involved changing parameters to make the whole system work the way the customer wanted. Which, of course, changed every few minutes. But I was able to adjust the signals and hardware timing on the fly, and the system integration phase took very little time.

Summary: VDIP1 worked well for me, once I got through the initial learning curve, on a system where the actual code was very Simple but the configuration files changed dramatically (and frequently!). Buffer your comms, and use hardware handshaking.

The FTDI USB-to-serial chips work great too. I've used them a couple of times, including one project that involved some pretty serious abuse to the poor chip. Which it survives nicely.

And serial bootloaders are already written.

But you might consider a USB-to-serial cable, and a standard serial port connection on your board. Or even a USB-to-serial cable plus a 232-to-TTL converter (or the FTDI cable that does this), and then just have a small header on your board -- 3 to 5 pins. Saves board space, and the connections are easy to replace.

And yes, I did notice that your original post seems to imply that you want to send a storage device to the field, not send a laptop to the field. Just pointing out other options.

YMMV. (and other disclaimers)

[Guest]

Thanks for all the replies. I do not want to have to hook up a PC as many pointed out. Just send out the key and update.

The is absolutely no need on this project to move to an ARM or something that complex and run Linux. The project itself is VERY simple. Its this bootload from key that is killing me. So after doing more research, I found this little gem:

ghielectronics.com/faq.php?id=5

Looks like the VNC1L but a little more friendly. Although I also found that the VNC1L seems to take care of all the FAT issues (and so does the USBwiz). So if I need to do USB, I think I will go with either of these chips. Otherwise, I guess I will use MMC.

Thanks again, I will let you know how it goes!

[asmallri]

I am currently developing an SD bootloader targeted to the PIC24F family. The initial implementation is on the Explorer 16 with the PIC24FJ128GA010 processor. The bootloader includes the ability to bootload the PIC and/or external EEPROM.

The bootloader incorporates a stripped down FAT implementation - main restriction are the configuration, PIC hex file and EEPROM hex file are each limited to 8.3 name format (actually 7.3 if written with a system supporting long file names) and the files must be located in the root directory.

Development is well advanced and the software should be ready in about 2 weeks.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[ckielstra]

[treitmey]

what about a keyfob programmer?
http://microcontrollershop.com/product_info.php?products_id=984