LPC from scratch

[westfw]

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. ...  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.

Ah, a subject near and dear to my heart.  The early cisco "Terminal Server" code ran in about 512k of memory on a 68000 (RAM, including both data and instructions.  But rather heavily dependent on the all-ram architecture.)   That included IP/TCP/Telnet/rlogin/slip/ppp and probably some other stuff, though it was a tight squeeze...  IMO, it should be relatively easy to fit equivalent code on something like the TI "Connected" Tiva Launchpad (1MB flash, 256k RAM, $20.)   But oh, the amount of infrastructure that needs to be recreated!

[replacing the boot ROM]

I assume that anything called "ROM" is not eraseable or re-programmable by a user.  However, it should certainly be possible to put a more traditional bootloader in regular flash memory, and have it do whatever you want.  Especially given the ARM ability to redefine the vector table address.

[neslekkim]

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.

Same as ST did with Nucleo-boards: http://norwied.wordpress.com/2014/05/07/first-steps-with-my-nucleo-f401re/

[nctnico]

I assume that anything called "ROM" is not eraseable or re-programmable by a user.

Ask yourself how they program the bootloader during production. They already have flash on the chip so it doesn't hurt to put a little bit extra on it.

[dannyf]

Same as ST did with Nucleo-boards

The Nucleo board is interesting. The one I have has a st-link v1 harhdware and st-link v2 software. Totally weird.

[SirNick]

Ask yourself how they program the bootloader during production. They already have flash on the chip so it doesn't hurt to put a little bit extra on it.

Mask ROM?  I dunno.  I read a forum post somewhere where one of the mods recommended "using a newer chip" to troubleshoot a bootloader issue, because the OP's ROM version was old.  Circumstantial, but indicative that it isn't fixable with a flash update.

[nctnico]

That is because the tools don't support reprogramming the bootloader flash.

[SirNick]

Unless you have info the rest of us don't, it doesn't seem to be a limitation of the tools.  It's that the bootloader region isn't an addressable flash sector, if it's flash at all.

From ISP, you should be able to read this area of memory... haven't tried yet, but I will in a bit.  I expect writes (with the write-to-RAM command) to fail since it's not a RAM address.  Likewise, since there's no corresponding sector number, the copy-RAM-to-flash command won't be able to address it.

If there is a way to write to this region, it's not exposed by ISP.  IAP (in-application programming) has a limited set of the same commands -- namely, copy-RAM-to-flash, which still requires a sector number as the destination.  So no-go there either.  Not sure what would happen if you set a pointer to that region in the memory map and tried to write to it.  Maybe a null-op, maybe an exception, who knows?  I doubt the contents would change in a way that persists across power-cycle though.  Curious parties are welcomed to give it a try and report back.

[nctnico]

You are overthinking things. As I wrote before: many years ago I have read an article from someone who claimed he could overwrite the bootloader in an LPC chip. I just can't find the article. He got that information from disassembling the bootloader. It is easy enough to do. Just write a piece of code which dumps the bootloader area as a hex file to the serial port, save to disk and disassemble it. There is an undocumented peripheral which deals with erasing/writing the flash.

[SirNick]

You are overthinking things.

I don't think I am:

If there is a way to write to this region, it's not exposed by ISP.

Which, so far, is true.  Although maybe with the caveat: "Not exposed by documented ISP commands".

As I wrote before: many years ago I have read an article from someone who claimed he could overwrite the bootloader in an LPC chip. I just can't find the article. He got that information from disassembling the bootloader. It is easy enough to do. Just write a piece of code which dumps the bootloader area as a hex file to the serial port, save to disk and disassemble it. There is an undocumented peripheral which deals with erasing/writing the flash.

Did you really mean "undocumented peripheral"?  Or, did you mean ISP command, or an undocumented instruction used by the bootloader?  Anyway, could be possible, and while slogging through uncommented, symbol-less, disassembled code isn't my idea of fun, it might be possible to find that functionality if it exists.

I just finished writing an Intel Hex library for my flash util, so I'm not too far from implementing read/write functionality.  Or, someone else can use one of the existing tools to do this.  Boot ROM is 8kB at 0x1FFF 0000.

[neslekkim]

Same as ST did with Nucleo-boards

The Nucleo board is interesting. The one I have has a st-link v1 harhdware and st-link v2 software. Totally weird.

Hm, I thought they all had st-link v2-1? (not sure what differs between v2 and v2-1 though), i have 8 of these now (ok, kinda stupid, but couldn't help myself), and all seem to have exact same design, other than the main chip, wonder if all also are pincompatible?, so that is the criteria to become an nucleo board?

[dannyf]

They used different chips with the same packaging. So aside from those arduino-like pins, pin out is mostly the same but not identical.

Nucleo boards seem to be mbed designed and st manufactured? There is this online ide/compiler from mbed that sets them apart. But the code can be compiled offline, using mbed library or gcc.

They are good value for the money, particularly vs. the cost of the chips + ebay boards.

[neslekkim]

yes, about $10 pr board, I can dig that all day long.

[zapta]

I am spending some time creating my standard LPC based development environment, libraries, etc, similar to what I had with atmega328. The goal is to have C/C++ code line that can easily installed on lpcexpresso, can be shared by multiple projects (hence the library), targets barenone boards with lpc11uxx MCU's and is a easy and practical starting point for arbitrary projects. Currently I  am testing it with  Embeded Artists QSB lpc11u35 which is very minimal (good) but will later cut my own application specific boards.

I chosen LPC because of the OS agnostic Eclipse based IDE and the ability to update the firmware via the USB port, no tools necessary (for debugging I am a using Link 1 board)

So far it is going well and I am happy with lpcxpresso. It is quick, configurable, git friendly, the cross references work great, and it feels like home.

Here is my hello world example (binary size ~5K).

Code: [Select]

#include "ezlpc.h"

#include "usb_serial.h"
#include "system_time.h"

int main(void) {
  // Initialization
  ezlpc::setup();
  usb_serial::setup();

  // Actual program
  for (int i = 0; ; i++) {
    usb_serial::printf("Hello world: %d, %04x, %d\n", i, i, 10000 / i);
    system_time::delay_ms(1000);
  }
}


[paulie]

Unless you have info the rest of us don't, it doesn't seem to be a limitation of the tools.

I suspect that is exactly the situation. Like the ST boot "ROM" which can be altered but only with a special upgrade utility. The upgrade files themselves are highly encrypted. One fellow claimed to have broken it but no evidence this was true. Out of several thousand Baseflight users no single case of corruption. Like with AVR and PIC there are most certainly hardware features available to prevent reading too.

[Brutte]

One fellow claimed to have broken it but no evidence this was true.

Any reference?

[paulie]

http://www.taylorkillian.com/2013/01/retrieving-st-linkv2-firmware-from.html

It has been discussed here before. Like a lot of this stuff appears to be typical internet trolling. Some say the chinese clones used it but subtle differences belie that. Versaloon is another attempt that flopped.

I would like to know if there is any more information on programming LPC with STlink. It's not an option in Flashmagic.

[SirNick]

Via SWD?  No idea.  What would be the point, vs. using the boot ROM or USB disk mode?  Were you thinking the ROM area might be accessible that way?

Minor progress update:

Hoping to have the test harnesses for UUencode and Intel Hex libraries finished today.  (EDIT: This is done.  Added a .tar file -- because tar.gz/bz2 isn't supported by the forum -- to the boot ROM discussion page.  Added an index section on the first post to make it easy to find these things.)

Once they test out to be (presumably) bug-free, I'll start hammering on memory R/W code.  I have a few changes in mind to get more of the session code to be usable both from the PC app and as an IC-to-IC library.  Might add that this time or wait until I start refining it later on.  (It's not terribly elegant code just yet.  First draft never is.)

I would like to get some test code loaded onto the chip and start verifying basic I/O before publishing reference schematics, just to avoid having anyone duplicate mistakes that may not be apparent yet.

Until then, keep up the conversation. 

[westfw]

BTW, I tried reading the STM32F103 boot rom, and it doesn't work (presumably it bus-errors due to protection failure, and uses the same protection mechanism as YOUR code in protected flash would have.)  The flash write mechanism (on ST) has 32 or 64 bits worth of "keys", which doesn't sound promising from a "guess" point of view.  I'd strongly suspect that if the boot "rom" isn't secure, then neither is any code a customer would put in flash...

[SirNick]

Not necessarily.  LPCs have Code Read Protection support.  You write a certain value to a certain location in flash to set it.  CRP is pretty serious business.

At level 1, you can't write to RAM below a certain address, you can't write to flash sector 0, you can't erase sector 0 unless you erase everything, you can't read memory at all...

At level 2, you can't even write to memory anymore.  You can't execute from arbitrary locations in memory, and you can't access SWD.

At level 3, you can't even get into ISP mode.  They also warn you that no future factory testing can be performed.

If you're worried about someone exploiting the boot ROM by replacing it with less secure code, you can just enable CRP at level 3.  Then, if the vendor hasn't back-doored the code themselves (which is ALWAYS a risk), it probably can't happen.  At least, not in any way that couldn't be used even without the aid of ROM hacks.

[SirNick]

I added code to start poking around in memory, and ran into something I thought was interesting given the previous discussion about boot ROM.

Code: [Select]

# ./serial --verbose -p /dev/ttyUSB0 -c 12000 -i 47193f47 -l 23130 -t 500 --check 0,30 --prepare 29,1 --copy 0x1fff0000,0x00078000,4096
Serial port /dev/ttyUSB0 opened
Synchronizing...  OK
Setting clock frequency... OK
Disabling echo... OK
Getting part ID... 0x47193f47
Getting unique ID... 0x01011b1e 0x53320000 0x52d1a647 0xf5000003
Getting ROM version... 4.8
Unlocking flash with code 23130... OK
Checking for 30 blank sectors starting at 0
Requsted range is blank
Preparing 1 sectors for write starting at 29
done
Copying 4096 bytes from 0x1fff0000 to 0x00078000
Copy failed: (4) Source address is out of mapped region
OK, you can't copy directly from the boot ROM region to flash.  Wonder if it will let you copy it to SRAM first?

Code: [Select]

# ./serial --verbose -p /dev/ttyUSB0 -c 12000 -i 47193f47 -l 23130 -t 500 --check 0,30 --prepare 29,1 --copy 0x1fff0000,0x10000000,4096
Serial port /dev/ttyUSB0 opened
Synchronizing...  OK
Setting clock frequency... OK
Disabling echo... OK
Getting part ID... 0x47193f47
Getting unique ID... 0x01011b1e 0x53320000 0x52d1a647 0xf5000003
Getting ROM version... 4.8
Unlocking flash with code 23130... OK
Checking for 30 blank sectors starting at 0
Requsted range is blank
Preparing 1 sectors for write starting at 29
done
Copying 4096 bytes from 0x1fff0000 to 0x10000000
Copy failed: (5) Destination address is out of mapped region
Nope.  Can't do that either.  Presumably, you can't copy TO SRAM at all, just from SRAM to flash.

So, now ya know.

[Jeroen3]

Bootloader flash is masked in the chip. This cannot be changed.
That's why the first generation of the dual core LPC's have this reset bug when booting from SPIFI memory.
http://www.nxp.com/documents/errata_sheet/ES_LPC43X0.pdf
There also is a USB driver api available in some parts. Don't know about this, might be masked as well.

But, there are also a lot of OTP bytes that are not documented, for oscillator trim for example, as well as multiple peripherals (or entire cores) that are turned off.
Some LPC's can also enable or disable features using a specific pattern at a random location in user flash.
Good luck finding those if they're not documented.

If you want to read all the chip's memories, look into the programming algorithms used with your ide. For starters, they execute from ram.

[nctnico]

No need to mess with programmers. Just create a piece of firmware which dumps the content of the boot rom as a hex file to the serial port. Shouldn't take more than 20 lines of code. From there load the hex file in a dissassembler. One of the remarkable things about machine code is that a dissassembler gets into sync with the code pretty quick even if you start at a completely random address.

[paulie]

Bootloader flash is masked in the chip.

By that if you mean masked ROM (which is not flash BTW) then it's unlikely. The same claim was recently made for 3 other MCUs (AVR, PIC, STM32) and was demonstrated not to be true. Purposely make difficult to alter for obvious reasons but not bulletproof. Do you have a credible source for your information?

[SirNick]

Do you happen to know if this area is actually readable during normal execution?  I would think so, since it has to be executable (and thus, readable) during boot.  But, who knows, NXP could protect it from user code.  It's apparently unavailable from the boot ROM interface.

In reality, I don't know if there's anything to gain by looking at the ROM, I'm just curious if it can be done by normal means, or if it takes some kind of ... "persuasion" to accomplish.    I'm just having fun poking at them for now.

Quick status update on the flash code:

I have extracted the platform-specific code from the ISP client interface.  It should now be cross-platform compatible.  The POSIX stuff (basically, main() and the serial interface parts) are in their own module.  I'm working on porting this part to Win32 Console, and providing a lightweight abstraction interface (for the serial calls) for AVR / Arduino, and LPC.

Since starting this project, I've realized that the flash util needs to have a map of flash sectors to memory addresses, since this varies by part; and needs to know where in RAM it can stage incoming data before it gets written to flash.  For now, the CLI exposes the internal commands 1:1, so you have to work this out on your own.  But ideally it should be as simple as choosing a hex file and having the util handle the rest.  In other words, a part database.  Yuck.  Would be nice if this info was available from the boot ROM, since it's inherently going to be device-specific code anyway......

Also:  Windows programming sucks.  FormatMessage() is like strerror() and sprintf() bundled into one, with a little iconv() thrown in for good measure.  But the real surprise was finding that the C99 integer types (intXX_t) don't exist in VS2010.  2010!!  ><  And, while VS2013 finally got around to adding them, at least according to a note on one of the betas, sprintf() works now, but sNprintf() didn't make it because they "ran out of time" implementing it.  So, when it comes down to adding a byte counter in your format loop, or having user code suffer buffer overflows, I guess the choice is obvious.  Oy vey......

[paulie]

NXP could protect it from user code.

It's SOP for most MCUs to have multiple options for read and write protection. Usually protection from outside access (ISP), protection from inside (user code), and protection from everything except hidden protocols (factory id, serial #, etc). I have intimate knowledge here regarding PIC, AVR, and STM32. Not LPC but I'm guessing with 99.9% probability no different.

Note that masked ROM is very expensive now compared to flash. Just the opposite of how it was back in the old days.

Also:  Windows programming sucks.

Two words: Py... Thon...