New To Arm - Working With An LPC2148

Development Boards MicroMod
1

Ive got some code that runs on a PIC chip, and Id like to learn ARM and re-create the functionality. Id also like to add other features down the line.

The first question I have (and I plan on replying to this post and/or editing in new questions) involves the USB bootloader.

It seems that the SparkFun bootloader uses an SD card for storage of the firmware. While this is all fine and dandy, this would add more parts/code/cost to my project, so Id like to use the onboard flash instead. In theory, I should be able to write the file to the flash starting at the end (or at a pre-defined size), overwrite the code at the beginning, then erase whats at the end of the flash.

I dont plan on my code being very large, and the 2148 has 512Kb of memory, so this would allow for /roughly/ 256Kb flash files; much bigger than I plan on it being.

Does this make sense? Does anyone know if its been done before, so Id have some sort of reference?

Thanks!

2

SpikedCola:
It seems that the SparkFun bootloader uses an SD card for storage of the firmware. While this is all fine and dandy, this would add more parts/code/cost to my project, so Id like to use the onboard flash instead. In theory, I should be able to write the file to the flash starting at the end (or at a pre-defined size), overwrite the code at the beginning, then erase whats at the end of the flash.

That sounds like a secondary bootloader. The LPC2148 has a primary bootloader in a protected area of flash that you can use to program the flash directly via UART0 using the FlashMagic tool:

http://www.flashmagictool.com/

3

This is the SparkFun bootloader I was talking about:

http://www.sparkfun.com/commerce/tutori … ials_id=94

I didnt know there was a primary bootloader in protected flash - that makes life much easier. If my assumption is correct, that means I can trigger ISP mode with the serial control lines, such that I dont need a JTAG programmer, right?

Also, I suppose the SparkFun bootloader would be a secondary one. Basically, Im looking for it to detect the USB cable (the same way as the SFE one), but instead of writing the flash file to an external SD card, Id like to write it to the second half of the on-chip flash instead.

4

Use a USB to serial (not RS232) - SFE sells them. Built-in bootloader will use that.

Using JTAG is better - fast download, breakpoints, etc.

5

Im hoping to have a flash-type uploading scheme because this is eventually going to be a product I want the end-user to be able to update without any additional hardware

6

SpikedCola:
Im hoping to have a flash-type uploading scheme because this is eventually going to be a product I want the end-user to be able to update without any additional hardware

Great. As as developer though, using JTAG and something like IAR or Keil with, say, J-Link, is a huge benefit to productivity and speed of development. That done, you can send out .hex files that can be installed via the serial port bootloader.

7

SpikedCola:
Also, I suppose the SparkFun bootloader would be a secondary one. Basically, Im looking for it to detect the USB cable (the same way as the SFE one), but instead of writing the flash file to an external SD card, Id like to write it to the second half of the on-chip flash instead.

I assume that your product has a USB connection only, and you want the end-user to be able to download new firmware via USB. I also assume that you will program the secondary bootloader before shipping your product, but I am not assuming that you want to use Mass Storage.

The LPC2100 is very flexible, so there are many ways to implement a bootloader/firmware upgrade scheme. The best method depends on how your product operates, what the connection is, what device class is being used, what platforms the device is connected to, what application code is running on the platform, etc.

The Sparkfun and other USB bootloaders use USB Mass Storage to transfer firmware, which is a neat trick if you already have a Flash storage that is exposed as Mass Storage. The limitation is that the Flash needs to look like a disk with 512 byte sectors, and will have a FAT16 file-system written to it. If you are using the internal Flash, the USB Mass Storage method is not really suitable for this. I guess there could be a way to spoof a 512-byte sector filesystem but I think it would be pretty messy.

Other ways to upgrade over USB are DFU, a protocol designed for firmware download. The device would reboot into DFU mode, and the user run a program supplied by you on his PC. If you are using USB virtual COM port, then you can define a protocol to download firmware over that. There are more advanced options such as composite device classes.

Writing your own bootloader is kind of jumping in the deep end, but would be a good way to get to learn the internals. Personally I try to keep things simple and try to work with existing tools, but I have also written both custom bootloader and downloader applications where necessary.

8

bobcousins:
I assume that your product has a USB connection only, and you want the end-user to be able to download new firmware via USB. I also assume that you will program the secondary bootloader before shipping your product, but I am not assuming that you want to use Mass Storage.

This is absolutely correct. Im not sure if I was explaining it unclearly before, but youve picked up on exactly what I want to do.

bobcousins:
The LPC2100 is very flexible, so there are many ways to implement a bootloader/firmware upgrade scheme. The best method depends on how your product operates, what the connection is, what device class is being used, what platforms the device is connected to, what application code is running on the platform, etc.

Just so the information is out there, my ‘product’ will (should, anyway) use the SPI protocol to communicate with a flash controller, which is then passed to a program on a computer over USB. This code I have already (this is a continuation of a previous project, started by someone else). Thats essentially what it HAS to do. The first fun feature is this one, the firmware upgrade scheme.

bobcousins:
Writing your own bootloader is kind of jumping in the deep end, but would be a good way to get to learn the internals. Personally I try to keep things simple and try to work with existing tools, but I have also written both custom bootloader and downloader applications where necessary.

I did some thinking about other features Id like to have, and one thing came to mind - a way to make the unit self-contained, having a “read” button that would read the SPI flash without a computer. I think this is very possible, considering how powerful the ARM processor is. Ive also concluded that I will need some place to store the file that I read (which could be anywhere between 16MB and 512MB), which means I will need some kind of additional storage anyways. Instead of reinventing the wheel and trying to spoof some kind of FAT16 partition in flash, I think I will stick with the SD card idea, and use the SFE bootloader. This would give the user the ability to drop in the flash, it would give me the storage space I need for the file that gets read, and it would give the user an easy way to get the file off the SD card.

Ideas?

9

Having an SD card may seem like overkill, but it saves a lot of work down the line. If you are not worried about exposing the firmware to user (accidental overwrite/hacking) then it’s easy for developer and user.

If you already have an application talking to the device, then it would be relatively easy to include a firmware upgrade option in that. The firmware can self-program via calls to the built-in bootloader, but you still need to consider issues like what happens if the upgrade is interrupted. You can also jump to the USB bootloader from the main firmware I think, so you could use that method initially and consider a more tailored solution later.

10

Would it be possible to put the ARM in some sort of “firmware-upgrade” mode that switched over to a USB serial port, and I could send a command to enter bootloader from an application, along with a dialog and such to upload firmware to?

11

I think this is what you are looking for: http://www.nxp.com/documents/applicatio … N10711.pdf