-
In a similar vein to the 1$/1M and ghetto ARM threads, here's my work-in-progress attempt at minimal C development on NXP's LPC Cortex M series.
What are you doing, and why?
This is part learning opportunity, and part practical project. My "dev board" is a prototype 8-port remote serial console box, intended to provide access via Ethernet, USB, or local DB-9 RS-232, to (up to) 8 serial devices, such as a managed network device like a router or switch. I come from a telecom background, and this is usually the kind of job where one would use an older Cisco router with an async serial card, or a dedicated serial concentrator appliance. Both options are easily >$1,000 devices, and I figure I could build something cheaper that is "good enough" nearly all of the time.
However, all that is purely to illustrate my motivation for learning ARM -- the hardware is not particularly relevant to this discussion. The point of this thread is to document the process of learning how to build an ARM Cortex M device of your own. This can be as simple as a breakout board exposing only power, reset, UART0, and the ISP_Enable pin; or it can be some pet project like mine. As long as you have TTL serial access to an LPC with a boot ROM providing ISP-over-UART support, it's all good.
About the hardware
I'm tackling a complicated PCB design as well, which is probably not a great way to begin, but I'm stubborn like that. Hopefully, my errors can serve as a useful lesson in basic hardware implementation as well. Someone asked for reference designs recently, which are relatively difficult to find (compared to, say, AVR.) I'll publish relevant parts of my design (don't want to muddy the waters with extraneous detail), where hopefully anyone more experienced can point out potential problems along the way. Anything I publish here is free to use however you want. Use it as a reference, copy it verbatim, whatever.
OK... In my case, the dev board's main CPU is an LPC4078 -- a Cortex M4F (it actually has a second M0 core, but nevermind that for now.) It will also have one LPC812 (Cortex M0+) per downstream serial port (they ended up being cheaper than dedicated UART ICs, and allow programmable TX/RX LED control for free), so there's a bonus goal of having the main CPU flash the secondary CPUs as well. The datasheets for these two parts (well, part families actually) seem to have 100% compatible boot ROM implementations, so I'm hoping that's the case across the product line, but I don't make any guarantees. The 812 looks like a neat little chip on paper, and it's inexpensive, so if you're wondering where to begin, that would be as good a place to start as any. (NOTE: It does not have an onboard ADC, if that matters to you.)
As for the software...
The only assumption is that the code will compile with GCC. I would prefer the code to be as cross-platform as possible, and so I also have IAR Embedded Workbench installed for compatibility testing. My preferred coding environment is Kate (KDE's multi-document, syntax-highlighting, general-purpose editor), Make, and GCC. Anyone should be able to follow along with their choice of editor, and the GNU toolchain. I'll provide info on how to set all that stuff up when I figure out for myself.
(In the past, I have leaned on Gentoo's automated cross-compiling framework to compile for non-native architectures, but I would like to learn more about how to set up a build environment that isn't tied to a specific distro.)
What's next?
Step one is to establish communications from a PC to the LPC's boot ROM using a standard FTDI TTL serial cable. There are existing tools to upload HEX images, but I said "from scratch" and I mean it, so I'm brewing a DIY implementation that should compile and run in any POSIX-compliant environment. This is where things get complicated for Windows users, as it's not particularly well suited to POSIX applications... If I can, I'll try to write a Windows console application port as well. In theory, OS X should be able to use the POSIX version. I'll try to verify this.
It's up to you to provide a the TTL serial interface. I use a standard FTDI USB-to-TTL cable. It has a 5-pin 0.1" female header on the end with Gnd, +5v (USB Vbus), and 5v-tolerant 3.3v signalling lines for TX, RX, CTS, and RTS. AVR fans should be familiar with how avrdude uses RTS to reset the MCU. I'm going to try to duplicate this behavior. Take it or leave it. My software will happily wait for you to manually reset the MCU if you prefer.
OK, but why?
None of this is a practical, low-effort, time-to-market driven approach. It's 100% wheel-reinventing, for the purpose of learning how to make your own wheel. A typical complaint from ARM newbies is "where do I start?" This guide comes from a fellow ARM newbie wondering where to start. I don't know, so I'm figuring it out, and sharing what I learn along the way. I'll make mistakes, and I'll do things in an unnecessarily difficult and time-consuming way. At least I hope so. Be patient and point it out if you see me leading others astray. Once I have a more or less workable solution, I'll condense the material and post it on the web.
Alright, here we go.
EDIT: I'll try to keep a section here up-to-date with links to pertinent topics and files.
Boot ROM Serial Flash Code: revision 11 (Thu., Oct. 14, 2014) -
Here's a shot of the dev board I'm working on. The LPC4078 is the LQFP-100 package in the middle, next to the DB-9 port. The FTDI cable connects to a header to the right side.
I've populated one "port" with an LPC812 and the RS-232 level translator. The 812 is the TSSOP-20 on the far left, above the RJ45 cluster on the bottom. It's the one oriented top-to-bottom. The level translator (an Intersil part) is rotated 90-deg (left-to-right) below it. The main CPU has the ability to selectively trigger ISP mode for each 812, which will be used down the road for IC-to-IC ISP.
Next, I'll explain the boot ROM protocol.
-
The boot ROM expects a connection at 9600 baud, 8 data bits, 1 stop bit, no parity, with software (XON/XOFF) flow control. If you start a terminal application, you can probe the device to see if communications are working. Here's the basic flow:
- You reset the device and assert ISP_Enabled. (Without any user code on the IC, it'll default to the boot ROM w/o having to assert ISP_En.)
- The host (PC) sends '?' repeatedly until the CPU responds with "Synchronized<CR><LF>".
- The host responds "Synchronized<CR><LF>". The CPU should respond "OK<CR><LF>".
- The host then sends the actual system clock frequency, in kHz, as a decimal number: "12000<CR><LF>". The CPU should again respond "OK<CR><LF>".
- You are then free to start throwing commands at it. For example you can turn echo off, or change the baud rate and stop bits to your preference, query the part ID, unique ID, and boot ROM version, or start reading / writing memory.
Now, the docs say you must terminate lines with CRLF, and any spurious CRs and LFs will be ignored. It also says the CPU will use CRLF to terminate its lines, however, it seems like I only get CR from the device. That could be something the kernel is doing, but you might expect to deal with CR and/or LF as a matter of course.
To start poking at flash, you need to first unlock flash access. This requires a code (presumably to prevent line noise from inadvertently sending an unlock command) that you have to get from your part's data sheet. Flash sectors must also be prepared for writing (basically like turning off a per-sector read-only flag). Then, you can erase them, copy from RAM to flash, etc. All flash access is based on sectors, starting at 0. Flash sectors are not all uniform in size. It's common to see e.g., 4KB sectors for the first few, then 32KB sectors for the rest. Check the data sheet.
RAM access is by address rather than sector, and must be word-aligned, or divisible by 4. There's no way to write directly to flash, so you must pre-stage writes in RAM first. You then copy from RAM to flash.
There are commands to check flash sectors for blankness (to avoid gratuitous erase cycles), and compare memory (e.g., RAM and flash to confirm valid contents after a write).
All data transfers are UUencoded, resulting in a conversion from 3x 8-bit data bytes to 4x 6-bit chars. If you have less than three bytes remaining, pad them with 0x00. The resulting chars are shifted into the 0x21-0x60 character space to avoid conflicting with non-printable control characters (like ESC or XON/XOFF). Do this by taking the value and adding 0x20, except if the char's value is 0x00 -- then you add 0x60.
Data is sent in lines of up to 45 data bytes (60 chars) with the length of the line (number of 8-bit data bytes) converted to an 8-bit integer, and shifted up by 0x20 (again, to be a printable character.) This "length" byte is the first byte in each line, immediately followed by the 60 UUencoded characters, and then CRLF.
You can send up to 20 lines at a time, then you must send a checksum. To generate a checksum, simply add the values of each incoming data byte as it's encoded. The resulting decimal value (byte[0] + byte[1] + ... + byte[44], for each line, for 20 lines) is sent as an ASCII number (e.g., "25140") followed by CRLF. You should then get "OK<CRLF>" back from the MCU, or "RESEND<CRLF>" if the checksums don't match.
When you reach the end of the data, your last group will potentially be less than 20 lines, and less than 45 bytes on the last line. Send a final checksum and watch for "OK<CRLF>". You tell the boot ROM in advance how many bytes you're going to send, so there's no ambiguity.
Receiving data works the same way, but in reverse.
I'm attaching the code I'm working on. It's incomplete, and I'll probably change parts of it along the way, so don't take it too seriously yet. However, it does work so far as establishing communications, and fetching IDs and such. I'm working on the memory access parts now.
Quick-start:Code: [Select]# gcc -o serial uuencode.c intelhex.c unix.c unix-cmds.c
# ./serial -p /dev/ttyUSB0 -c 12000 --verbose
For help:Code: [Select]# ./serial --help
EDIT:
REV 10: Fixed some issues and cleaned up main() a little. Added revision to version info. (./serial --version)
REV 11: Fixed some bugs, added line encode/decode to UUencode library, added Intel Hex library, added tests.
-
Judging by the number of LPC fans here this thread should be a great success. Your project board looks very interesting too. It should provide a great minimum development platform partially populated yet extremely powerful end product when completely built up. I can't wait to see how this turns out.
One question though: do you know of any serial flash programming utility that works under winblows similar to the ones from ST? This would be of great help to the majority of users who might like to play on their home desktop. -
One question though: do you know of any serial flash programming utility that works under winblows similar to the ones from ST? This would be of great help to the majority of users who might like to play on their home desktop.
http://www.flashmagictool.com/
sca -
Thanks sca. It's quite compact and installed easily. My chips haven't arrived yet but looks like I'll be ready when they do. This is my 4th venture into new ARM parts since starting out a few weeks ago and looks like the only promising one other than ST for cheapo quick start. So far two of the others turned out not to even have a bootloader. Fanboys and datasheets go through some pretty fancy footwork to hide this deficiency. Only $10-$15 loss but mostly it's the wasted time that can be very frustrating. This is looking real good so far.
-
You kinda have to try them all and see what speaks to you. The boot ROM is a pretty big deal to me, as is the ability to crank these things up to like 200MHz (for the 4078, not the 812.) I really want to like Atmel's stuff, but they're just not all that impressive. Nice datasheets though. IMO, ST doesn't have much going for them either, other than cost and ubiquity. (Although, for some, that's precisely what matters.)
In the end, NXP seemed like the way to go for me. The handy Xpresso boards were the nail in the coffin. That said, I will probably dabble outside of brand boundaries once I have my sea legs. Why not? They're cheap. -
ST doesn't have much going for them either, other than cost and ubiquity.
Admittedly being an ST fanboy at this point I look at it a little differently. Comparing $1 chips (103c to 812) it's 128k to 16k flash, 20k to 4k ram, 3 USART to 1, 16 ADC to none, etc so for my uses ST comes out with a lot more going for it.
If we look at similar features it's probably STM8003 at $.21 vs $1.05 for LPC812M101JD20FP. In this case it almost does boil down to only a cost difference. Except maybe STM8s 5 ADC. Analog interfacing is important to me so that does tip the scales.The handy Xpresso boards were the nail in the coffin.
Here it does look like mainly a cost issue. Searching on Ebay it's $2-$3 for 003 demo board vs $15-$20 for Xpresso. Or $7 for 103 blue board. Not really significant for me because we are talking pennies in all cases for DIY.
Maybe there are advantages to LPC that I'm not aware of yet. When the chips arrive monday I'll have both up and running for a real hands on comparison and better position to judge. Possibly I'm attached to ST because it was my "first love". In any case I look forward to soon hitting some "strange".
-
How are you gonna debug this?
From what I know there's no good free (as in: no code size limit etc) IDE that supports debugging.
For STM32s there's CoIDE which is very good in my opinion (it's just custom compilation of Eclipse with some embedded debug-oriented stuff). -
Perhaps a better comparison would be LPC812 vs something like an stm32f030. I mean come on, the LPC812 is a shiney cortex-m0 while the stm8s003 is a crusty old 8-bitter that is two registers short of a very small register set. Are those 0.21 danny-bucks? Because surely the lpc can be had for lower prices than $1 if you put some time into it and scour the chinese market place, same as for those 100 stm8s003's. It's either that or compare distributor prices. Which I just did and that looks pretty good for the LPC actually.ST doesn't have much going for them either, other than cost and ubiquity.
Admittedly being an ST fanboy at this point I look at it a little differently. Comparing $1 chips (103c to 812) it's 128k to 16k flash, 20k to 4k ram, 3 USART to 1, 16 ADC to none, etc so for my uses ST comes out with a lot more going for it.
If we look at similar features it's probably STM8003 at $.21 vs $1.05 for LPC812M101JD20FP. In this case it almost does boil down to only a cost difference. Except maybe STM8s 5 ADC. Analog interfacing is important to me so that does tip the scales.
Regarding analog, I just looked it up for the lpc812 and am a bit confused. This here page and a few other ones seem to suggest the lpc8xx series has an ADC in it, but the datasheets I could find do not show any ADC. It only looks to have a comparator. Only lpc1100 and up has an adc in it. Or I am looking at the wrong datasheet? Because I was actually sortof expecting the lpc800 series to have an 12-bit sar adc in it like the competition. But apparently all you get is this lousy comparator, and off you go implementing your own delta-sigma. Yeah, maybe not...
Incidentally, the stm8s only has 1 adc in it. One single 10-bit adc with an analog mux (aka 5 channels). If only it had 5 adc's, that would have made my choice a whole lot moredifficultinteresting.
Besides cost and ubiquity ST also has nice hardware, shit vendor libraries and very nice indeed chibios going for it. Then again, NXP also makes nice chippies so maybe the LPC series is even better.
Anyways, looking forward to reading the rest of SirNick's adventures in LPC country.
-
How are you gonna debug this?
Eclipse works very well for debugging. But then again debugging is not really mandatory.
From what I know there's no good free (as in: no code size limit etc) IDE that supports debugging.
Regarding the LPC800 series: they have no ADC
-
Perhaps a better comparison would be LPC812 vs something like an stm32f030.
As mentioned before I dont see the F030 being in the running since F103 is much superior in every respect and costs less. Lots more F103 out there too. So you can compare the LPC with that one dollar for dollar or with the 003 feature for feature (except no ADC) in which case we can buy 4x more.Are those 0.21 danny-bucks?
No, "paulie-bucks":
Apparently this seller bumped up 2 cents since I purchased monday and probably another 1 or 2 cents by the time I finish typing. I suspect a couple hours spent searching over the next few days can get it back down there. No matter what less than a quarter each regular price. Note that the numbers mentioned previously are for similar quantities for both chips being compared. Either 100 to 100 or 10 to 10.Because surely the lpc can be had for lower prices than $1 if you put some time into it and scour the chinese market place, same as for those 100 stm8s003's.
From what I can tell LPC does not exist on the Chinese market. I would love to be corrected.Incidentally, the stm8s only has 1 adc in it.
My 003s have 5 channels. We can argue endlessly about what is an ADC and what is a channel but this level of discussion tells me I've made my point. No matter what the ST has INFINITELY more ADCs.
I do think SirNick is on the right track and all of the chips being discussed here stand out head and shoulders from the rest of the ARM crowd. If you are designing cell phones or just pushing a favorite oddball part due to romantic attachment then maybe not.
-
Edit: never mind, might possibly come across as a wee bit argumentative.
Question remaining after edit would be: since you say F103 costs less than F030.. I can get 10 STM32F030's for $7.00. I would love to get 10 STM32F103's for $6.99 or less, but cannot find anything even close. Got any link where I can buy F103's for roughly $0.70 a piece at moderate quantities (5, 10, 20)?
Anyways, I'll shut up and let SirNick get back to it. -
good project, great thread
-
Edit: never mind, might possibly come across as a wee bit argumentative.
Got any link where I can buy F103's for roughly $0.70 a piece at moderate quantities (5, 10, 20)?
You can't get F030 for that either. They are actually 90 cents (70+20) as can be seen in your link:
http://www.ebay.com/itm/STM32F030F4P6-IC-MCU-ARM-16K-FLASH-20TSSOP-10pcs-Lot-/291245778302
The truth is all chips mentioned so far, including the LPC, hover around a dollar. None are half the other, none 2x more. Pennies difference. So it really boils down to features and availability. Only two stand out there and F0 is not one.
BTW Arguments are how we learn which does not happen when everybody agrees. But this does drift off topic so moved here:
https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg520941/#new -
Perhaps a better comparison would be (..) the LPC812 is a shiney cortex-m0 while the stm8s003 is a crusty old 8-bitter (..). Are those 0.21 danny-bucks? (..)Regarding analog (..)Incidentally, the stm8s only has 1 adc in it. (..) Besides cost and ubiquity(..)
This "crusty old" 8-bitter is 7 years old and "shiny M0" is 5 years old. Living on the edge?
The volume price is indeed in the range of $0.20-$0.40 for that 8k device. As for analog, in the world of smallest uCs term "5 x ADC" is precise enough.
As for NXP - their (nice) forum was deliberately terminated by NXP staff. Not sure if the forum still exists.
Things you should be LPC-aware of*:- LPCXpresso is Eclipse based but with plugins jig disabled (no external add-ons possible)
- The LPCLink basic version has a 128kiB debugging limit
- No SWV on LPCLink. Of little importance for crusty old CM0
- Their IDE/GDB is not MI compatible and you cannot use a regular GDB there
- This IDE uses a proprietary xml format for IO views. No chance to change/add/remove/customize anything in their IO views.
- LPC Cortexes do not allow stopping peripherals (timers, transceivers etc) when core is entering halt mode. Debugging anything time or timer-related is a PITA on LPC chips.
-
One question though: do you know of any serial flash programming utility that works under winblows similar to the ones from ST? This would be of great help to the majority of users who might like to play on their home desktop.
With some LPC's with USB (e.g. LPC11u35), it's even easier. You hook it to your computer, it appears as a disk, you copy/drag your binary to it and you are done. -
Quote
With some LPC's with USB (e.g. LPC11u35), it's even easier. You hook it to your computer, it appears as a disk, you copy/drag your binary to it and you are done.
The other ones I know of are :
LPC11U68 (M0)
LPC134x (M3)
Most others have USB DFU and basic serial port (FlashMagic is a popular tool for the serial port).
I tend to like NXP as the bootloader in ROM can be a lifesaver. -
I was fascinating by the prospect of virtual drive flashing. That is until the $5-$10 per chip price tag came up.
It may be possible to replace the stock bootloader on one of the cheap ones like LPC812 but that would probably require a 12mhz crystal and may not fit. The old V1 Stlink worked like that but those are discontinued. -
I was fascinating by the prospect of virtual drive flashing. That is until the $5-$10 per chip price tag came up.
I see that as a small price to pay for a bit of luxury and I'm pretty sure you can find these controllers for a lower price in larger quantities. IMHO one of the mistakes people make is just looking at the price of a part instead of looking at the complete package they get. One of the major advantages of the LPC series from NXP is that the peripherals are kept the same between the low end and high end parts so porting or re-using existing code is a piece of cake. In the other thread 'One dollar... ' people mention using ST's library to make existing code compatible between controllers. With the LPC series you don't need that. Ofcourse you could say your spare time is free but if you spend some of it on working in the local super market you can make more money in 1 hour than the price difference between an easy to use chip or an obfustigated chip. -
I was fascinating by the prospect of virtual drive flashing. That is until the $5-$10 per chip price tag came up.
I see that as a small price to pay for a bit of luxury and I'm pretty sure you can find these controllers for a lower price in larger quantities.
Yes, easily half price, and the USB serial is also great for debugging or hooking the mcu to a computer for data, and the lpcxpresso idea/tool chain is easy to install and is os agnostic. Almost beats arduino
-
IMO, ST doesn't have much going for them either, other than cost and ubiquity.
OK, in light of the ensuing comments, I should really take that back. It's just my perception based on the things that were important to me when I was choosing a vendor, and not a qualified opinion in any way. I also managed to overlook the lack of ADC on the 812. I didn't have a need for it yet, so failed to notice it wasn't there. Kind of a set back for general hobbyist use without at least a couple channels. Oh well.How are you gonna debug this?
It's not really in the cards, at least for now. Emphasis on the "minimal C environment". This is targeted primarily for those wanting to really understand the nuts and bolts of ARM development, from the beginning. Those that are content to learn an IDE and approach development from a high level, with all the amenities, are probably going to find this primitive, and needlessly archaic. That's OK. I follow the evolutionary chart below.
-
It may be possible to replace the stock bootloader on one of the cheap ones like LPC812
AFAIK, it isn't. It's a boot ROM. (I am prepared to stand corrected though.) -
AFAIK it should be possible to replace the boot rom. It seems to be just flash. I recall someone has disassembled the NXP bootloader to find out how the flash is begin programmed at a low level but I never got his code to work.
-
Looking at the LPC81x data sheet, the memory map shows this:Code: [Select]
0x0000 0000 4kB Flash (810), 8kB Flash (811), 16kB Flash (812)
0x0000 4000 reserved
0x1000 0000 1kB SRAM (810), 2kB SRAM (811), 4kB SRAM (812)
0x1000 1000 reserved
...
0x1FFF 0000 8kB Boot ROM
...
The flash sectors, per the ISP section in the manual, show flash sectors:Code: [Select]00: 0x0000 0000 - 0x0000 03FF
01: 0x0000 0400 - 0x0000 07FF
...
14: 0x0000 3800 - 0x0000 3BFF
15: 0x0000 3C00 - 0x0000 3FFF
So, no overlap there between flash sectors and the memory region where the boot ROM is located. You could probably copy the ROM region to flash, and then change it... but AFAIK, you can't copy your changed code back to the ROM region again.
Anyone know if there is a way?