WARNING: The author is NOT your friendly neighbour. He has harsh opinions and these opinions may be expressed here or in the program's output.
There is a yahoo group lpc21isp, but since a few weeks I can't do any posts there any more. I don't know why - maybe I should do a browser update, or get a yahoo email acount or I don't know. Yahoo does not understand, that people don't want to be force to do tedious work all the time simple to KEEP things running. At least I do not. Good bye yahoo groups! That's why I replaced the lpc21isp-link in this page by the sourceforge page. You can find me on the LPCware.com forum
When looking at mxli's help, you will notice not only an enormous number of options, but also a very sophisticated style of passing information to the program. I dare to say, that you've never before worked with a program that allows such powerful, yet intuitive command-line options. For example you can specify the number 1024 as 1024, as 0x400 or as 1ki. And why should a program force you to write 12000000 instead of 12M for a crystal frequency, when we all know how easily we type a 0 in excess or forget one? Some options of mxli accept lists of tuples and you can write them down easily like for example "10@0x00,0x20@1024" for some byte ranges defined by length and starting addresses. In some cases, numbers can be replaced by symbolic names to avoid repeating the same number on the command-line or to rely on something that has to be extracted from the device. This reduces the probability of errors.
mxli tries to serve you. You tell it, what to do. Like most command line tools, mxli is the same every time you start it. There's no (hidden) state somewhere. If you use the same command line, mxli will do the same. This is very different from many a GUI application that remembers some things but not others or sets defaults that you have to change every time you start it and you can't do it in an easy and reliable way. With a command-line application, you can store as much settings as you want in a script file. You can build different wrapper scripts with different default settings around mxli, easily. mxli is a versatile component in your environment. You can't do that with GUI application. In that context, I want to cite an advice, given by Professor James Leslie Keedy in one of his lectures about operating systems:
"Provide functionality, not policy."
Command-line options are orthogonal. That means: when it comes to interpretation of command-line options, mxli's does not change the context of an option, depending on another. As an extreme example: if you decide to read the FLASH contents of a controller AND you also specify to output its serial number you will get both output to stdout with no error. There's no built in logic, that says: if you read a FLASH image, then reading serial number will corrupt the image output, so I ignore reading serial number. No. mxli does not constantly doubt the user knows, what he's doing. In general, any option A does not alter the meaning of any option B. The order of command-line options does not matter as long a you don't repeat them. Repeating an option (even with a different value) is NOT considered an error but a mechanim for overriding. Options causing actions on your LPC device are always executed in a predefined, immutable order: probe - identify device and/or boot code - read - erase FLASH - write FLASH - verify - execute program.
"What is an illegal copy?" He went on answering: "It's the original with the advertizing and the piracy warning removed. Only those who already paid for the original are forced to watch the advertizing and the piracy warning!"
In my opinion software needs only to be licensed, if it's not up-to-date and the vendor still wants to make money out of that b***sh*t. Write once, sell anywhere. No! So for short, mxli can be seen as an alternative to so-called 'professional' tools but without the license hassle.
mxli provides interesting features for code read protection (CRP) to protect your intellectual property, see below.
Sometimes, really new features emerge. Multiple flash banks appeared in the LPC1800 family, maybe earlier. LPC800 uses a new binary (opposed to a uuencoded) data transmission protocol not seen in any of the other families before. Such new features do require a modification of mxli's code. The good new is: that doesn't happen very often.
For the same reason, mxli supports debugging output by command-line switch to find out what's going wrong if something goes wrong.
| device | max baud rate | crystal | other options | remarks |
|---|---|---|---|---|
| LPC812M101 | 230400 | IRC | ||
| LPC1110 | 38400 | IRC | baud may be higher (untested) | |
| LPC1114FN28/102 | 115200 | IRC | ||
| LPC1764/1766/1769 | 230400 | IRC | ||
| LPC2106 | 230400 | 14.7456MHz | ||
| LPC2124 | 14.7456MHz | |||
| LPC2132 | 38400 | 12MHz | -E | |
| LPC2136/01 | 38400 | 12MHz | -E | |
| LPC2148 | 12MHz | |||
| LPC2378 | IRC | |||
| LPC4357 | 115200 | IRC | Keil MCB4300 |
$ mxli -nThis command tries to connect to your controller and outputs its type. If mxli times out, make sure the crystal frequency is correct for devices without IRC (LPC21xx for example). To perform flash programming, provide an image on the command line, either binary data or Intel-hex format:
$ mxli yourBinaryImageor
$ mxli yourImage.hex
If you don't know, how to create such a .hex or .bin file, or you don't know how to build one you can rely on, please visit Frank's "LPC17xx ARM Cortex M3 Assembly Language Example".
If your controller is a LPC21 family member running on a 12MHz crystal and your serial device is connected to /dev/ttyS0 then your command line should look like this:
$ mxli -d/dev/ttyS0 -b38400 -c12M -E yourBinaryImageThe -E option turns on echo in ISP communication protocol. This makes mxli wait for LPC's anwers before proceeding, especially while transferring image data.
$ tar xfj mxli-3.0.tar.bz2 $ cd c-linux-mxli-3.0 $ make $ cd programs/mxli3 $ makeThis puts the executable mxli into that final directory. Simply move it to the location you want. In the same directory, you can find the file mxli.1 which is a Unix man page. You can view it with man ./mxli.1 in that directory or (better) you can install it in one of your MAN_PATHs, typically something like /usr/share/man/man1 . Of course, you should have a look into the other directories of programs/ and compile and use these programs, too.
MANWIDTH=120 man --nh --ascii ./mxli.1 | enscript -fCourier7 -o - | ps2pdf - mxli.1.pdf or so .-)
I'm member of the NXP LPC Forum. If you run into trouble, please post there.
Known BUGS