I’m perusing David Lynch’s excellent tutorial on setting up the GNU toolchain, and happened to notice that programming the LP21XX looks to be a potential hurdle…
It looks like, in order to upload the compiled source into FLASH, I MUST have a USART connection to the chip. If I want to debug, I MUST have a JTAG connection. This is all well and good for a development board (like the Olimex prototyping board, also excellent), but how do people typically do this when the chip is on your own PCB? I have to believe there is a way to program this thing without adding a big honking DB9 connector and JTAG header to my otherwise tiny board. There’s not really room for this in my application.
JTAG and ISP via RS232 are the only options, it’s not necessary to have DB9 connector if you make your own RS232->ISP dongle which to work with 0/3V in Rx/Tx pins of LPC
Other solution is to implement a bootloader with your prefered communication link… SPI, I2C, CAN, etc…
Or just add three Test points to your PCB and design an extra mini-pcb with the ‘glue logic’ for the RS-232. So when you need to program a new micro connect both PCB with pogo pins.
Genius. Looks like I’ll probably debug the code on a dev board, then program the production system with a 2-pin RX/TX interface and the CP2103 breakout from Sparkfun. That way I can remove the JTAG adapter from my production design.
alejmrm: You kind of reminded me of another topic (that I should probably post in a seperate thread, but what the hell…): I want to be able to update firmware over USB. Do I necessarily need to write a bootloader to do this? If so, I’ll probably want to base the BL code on the existing on-chip USART bootloader from Philips. Does anyone know if the source code is available?
You could use the IAP (in-application programming) routines that are available on the chip if you wanted to write a USB bootloader. This could also be written into your end-program as well to allow for field and user programming. Check the user manual in the IAP section for details. I’m pretty sure Philips has some sort of app note on this, too.
Thanks Brennan. I wasn’t sure if the IAP could be used from Program space to overwrite the Program Space itself (ie: overwriting the code that’s running the IAP. Sounds a bit self-destructive…). In Boot Block, I would definitely go this route. Which leads me to yet another (off) topic:
If I write a new bootloader, how would I go about loading it onto Flash? My understanding is that the only way to program into flash is by using the booltloader that ships with the chip (ie: over UART). If I write a new bootloader (say one that uses USB instead of UART), and it doesn’t work, does that mean I’ve “broken” the chip? Seems like there would be no way to recover programmability after this, since the JTAG only programs to RAM (I think).
[edit]: After further persual of the User Manual, it looks like the BootLoader code (and interrupt vectors) is loaded into RAM, and run from there on reset. If I understand correctly, this means that the in-memory bootloader can be used to write a new bootloader to the Flash boot block, which is nice, but doesn’t answer my second question: If I screw up in code, how do I re-load the “old” bootloader?
You can’t overwrite the Philips bootloader using the IAP routines. The idea is to write a second-stage bootloader that accepts a new image via USB, and runs the installed image otherwise.
You shouldn’t ever overwrite the bootloader code that’s already in there (i.e. the default bootloader from Philips that comes on the chip already). Though it is possible to overwrite this, neither the Philips Flash Utility nor OpenOCD will overwrite the stock bootloader to my knowledge (correct me if I’m wrong, Dominic).
That said, you shouldn’t have to worry about screwing up your stock bootloader up if you mess up on your bootloader. In essence, your bootloader is simply going to be code that you write and flash into the LPC2148 just like any other code. Dominic said it best in that it is simply a second-level bootloader.
The way this is generally done is that the bootloader code that you write should run on startup of the chip as long as you don’t go into the stock bootloader (i.e., pull up P0.14 like you would to run any other embedded program). Your bootloader will then wait for some notification over USB that it needs to start the bootloading process. More than likely, you yourself will have to write a program on your host computer that does this. The computer will then send your bootloader the hex image and your bootloader will load it into flash or RAM (that one is up to you). When finished, you simply jump to the main function. Overall, there’s quite a bit of code to be written and tested to make a successful bootloader from scratch.
I wish you best of luck on this if you choose to pursue it since I, too, would like to have a USB bootloader on my 2148’s.
I have a pretty good feeling you’ll be using that pull-down more than once. Every time you make any change to the code in your custom USB bootloader, you’ll have to flash it into the 2148 using the stock bootloader (unless you get really creative with your custom bootloader).
brennen:
The computer will then send your bootloader the hex image and your bootloader will load it into flash or RAM (that one is up to you). When finished, you simply jump to the main function. Overall, there’s quite a bit of code to be written and tested to make a successful bootloader from scratch.
Yeah, I'm starting to get that :)
I wish you best of luck on this if you choose to pursue it since I, too, would like to have a USB bootloader on my 2148’s.
I might shell out for some of the CMX solutions (CMX-USB-BL, CMX-USB-EP). At least they come with source code.
Looks like I’ll have to do like Olimex, and stick a DIP switch, or low-profile jumper on there to pull up/down P0.14. Kind of sucks, as my PCB real-estate is very tight, and I only have about 4mm of vertical space to work with…
That looks really interesting, alejmrm, but that’s a USB 1.0 device class, is there an equivalent 2.0 class? USB is one of many things that I’m looking forward to learning about on this project (in a nutshell: it’s an mp3 player). I’m looking at one of two bootloader scenarios:
MMC: User program takes the firmware over USB, then saves it to a .hex file on the MMC card. On reset, the bootloader first checks for this .hex file. If it exists, it is written to flash, then deleted from the MMC card. Bootloader then jumps to the new User Code.
USB: User program waits for a predetermined “load firmware” command over USB. When it receives this command it jumps to the bootloader code (this is probably where the DFU class would come in handy), which then waits for the .hex file to come over the USB link, and writes it directly to flash. Once the EOF signal is received, it jumps to the new User Code.
Here are the things I’ve never done before:
MMC - FAT16 (actually, I’m using MicroSD/Transflash, since space is limited on the PCB).
ARM development.
USB (I’m really just looking for a virtual COM port, like the CP210X, but with full-speed USB data rates)
SPI (which I’ll be using to communicate with the VS1002, as well as the MicroSD).
OLED display programming (I’ll be using the OLED display from Sparkfun).
MP3 file format (for reading ID3 tags, and the like)
So yeah, got a nice learning curve to climb here. Gonna get me some dev boards when my tax return comes in, and start smoking them
Obviously I’ll have to write some sort of PC-side management software, to manage the device, upload firmware, upload MP3 files, etc. That’s not a problem, but I’d rather avoid having to write a windows driver to support my wonky USB device…
There’s a really nice project called EFSL (http://efsl.be) that implements a FAT file system. There is even a port to the lpc2xxx already that handles SD card commands and SPI.
I have written a simple USB stack for USB controller in the LPC214x (a USB 2.0 full speed device controller), see http://lpcusb.sf.net . It is still in development but working quite well already, with code examples for virtual COM port and mass storage. The stack has also been used for a bootloader/flashwriter application, see http://cvs.savannah.nongnu.org/viewcvs/ … =paparazzi
On the PC side you can use a standard device class (like HID, mass storage, CDC) which is already supported by an OS-supplied driver (you may need to supply an .INF file). Or if you implement a completely custom USB device, you can use libusb. As far as I understand, libusb installs a generic USB driver that it talks to, so your own USB code runs in “user space”.
Looks like I’ll have to do like Olimex, and stick a DIP switch, or low-profile jumper on there to pull up/down P0.14. Kind of sucks, as my PCB real-estate is very tight, and I only have about 4mm of vertical space to work with…
You should be able to use one of Silicon Laboratories’ usb to rs232 chips with gpio’s and connect one of the gpio’s to P0.14. Just 1 extra trace and a pullup/pulldown resistor
You should be able to use one of Silicon Laboratories’ usb to rs232 chips with gpio’s and connect one of the gpio’s to P0.14. Just 1 extra trace and a pullup/pulldown resistor
Being that the 2148 has built-in USB, I don't think you'd need that.
Looks like I’ll have to do like Olimex, and stick a DIP switch, or low-profile jumper on there to pull up/down P0.14. Kind of sucks, as my PCB real-estate is very tight, and I only have about 4mm of vertical space to work with…
You only need the switch as you prototype your USB bootloader code. Once you hit a finished design, you can simply put in a pull-up on your board and no switch, since you won’t need to use the stock bootloader anymore. However, if you’re going straight to a printed board before you develop your bootloader, you will indeed need to do either a jumper or a switch on your board so you can get your bootloader code loaded onto the chip.
brennen:
You only need the switch as you prototype your USB bootloader code. Once you hit a finished design, you can simply put in a pull-up on your board and no switch, since you won’t need to use the stock bootloader anymore.
I think I’d rather leave it in, since I may want to update the bootloader at a later date, and I’m not sure if the “second-stage” bootloader could overwrite itself in flash or not…
Plus, I wired the BSL pull-down through one of the existing buttons on my board. Now I only need to hold that button while resetting to go into bootloader mode. It’s one extra resistor, so I’m happy.
The second-stage bootloader will probably be initiated from the PC. That is, some command will issue from the PC to the User Code, causing it to jump into bootloader mode and prepare for a firmware update.
One questions I neglected to consider in all this discussion: Does the Philips bootloader utility support setting fuse/lock bits over UART? If not, I may need to stick a JTAG on there after all…
Hello folks. I am a newbie to the ARM7 world, committed to developing the LPC214X (planning on ultimately implementing 2142) and the USB peripheral.
We did purchase the Keil MCB2140, but are actively pursuing the GNU path. I’m working my way through Mr. James Lynch’s document entitled “ARM Cross Development with Eclipse version 3.” I downloaded and compiled the project called Demo2148_Blink_Flash, and am now sitting on page 106 of Lynch’s doc. I have the wiggler connected from my PC’s LPT port to the JTAG port of the MCB2140. I have a serial connection from my PC’s COM1 to MCB’s COM0 (I also tried COM1). I have version 2.2.3 of Philips’ Flash Utility. I have a USB cable connected which is simply providing power to my MCB2140 for the time being. 1) The flash utility won’t let me change the device type to anything other than LPC2106, and 2) no matter which button I press, the result is ultimately “Cannot communicate with test board.” Any suggestions would be greatly appreciated…
roach:
One questions I neglected to consider in all this discussion: Does the Philips bootloader utility support setting fuse/lock bits over UART? If not, I may need to stick a JTAG on there after all…
What fuse/lock bits are you talking about? This is not an AVR…
icktheslick:
The flash utility won’t let me change the device type to anything other than LPC2106, and 2) no matter which button I press, the result is ultimately “Cannot communicate with test board.”
Without seeing your setup, there are a gazillion things you could test. I’ll assume that since you have a production board that the RS232 link should not be the problem. Here are a few things you should check out:
Do you know for a fact the board is getting power? Also, are you sure that the 2148 is in proper working order?
Have you tried to hit the button to read the device type in the flash loader program (this is how you change the device type in V2.2.3)?
Do you have the correct COM port selected in the flash loader?
Do you have an acceptable baud rate selected? Since the chip uses the autobaud detection feature of UART0, only certain baud rates are available with respect to your crystal frequency. There is a table that outlines these values in the user manual I’m pretty sure. For example, I am using a 12 MHz crystal, and I have verified that 9600, 19200, and 38400 baud rates work.
Do you have a good serial cable?
Is your COM port on your PC working? Do you have it enabled in Windows’ Device Manager?
I personally have a hardware serial port, but if you’re using a USB-to-serial adapter, these can act kinda weird. Might check that out, too.
I can’t think of any more things right off the top of my head. Check into those things and you may find the solution to your problem. If not, let us know.
