Cortex M3/M4 with bootloader ROM

David Brown writes: ...

We've used a lot of LPC1768s in our project, usually JTAG programming. However, when we bought a tester development from an another company, their software wizard wrote a serial bootloader in a day.

Unfortunately I could not find manual for the protocol, but it must be available somewhere..

I'm using a flashless LPC18xx, and the serial bootloader protocol is documented in the part's user-manual. NB: the serial bootloader protocol for parts without flash is _different_ than the protocol used by parts withy flash. The protocol used by parts with flash is referred to as the "ISP" protocol in docs. The protocol used by flashless parts is much simpler.

I write an ISP protcol downloader in less than a day (I wrote it in Python, it would probably take longer in C), and the flashless downloader is even simpler.

There's an available open-source download utility written in Python for the ISP protocol available somewhere...

The LPC21xx and LPC18xx parts use the same ISP protocol. I'm _guessing_ the Cortex LPC17xx parts use the same one also...

Not for ARM, but we are using one for PIC32MX. The on-board serial bootloader is in C and the Window interface is in MSVC++, both available in source codes. It should not be too difficult to port the boot loader to ARM.

We also have used LPC1768/69 products and, like Mikko, use JTAG but also use the serial port for some updates and development work. The protocol is documented in the user manual. I think some of the guys use FlashMagic. There are other open source tools. Most of the LPC parts have a pin to control entry to the serial boot loader on startup. You can also enter it directly from the application code.

Be careful with the LPC1768/69 if you want to use the NMI. It is the same pin as the boot loader on startup pin but is opposite logic level.

Yes, we write our own bootloader too. The bootloader loads itself into RAM and executes there, allowing it to update itself if needed, as well as the main application.

The advantage of your own is that you can use your own interface, instead of UART1 using RS232 or whatever. For example in a modbus system you can update over modbus.

The other really nice way is for the bootloader to emulate a USB flash disk, customer can then just drag and drop the application .elf using familiar tools, no drivers required.

The STM32 devices.

Check out their application notes "AN2606 STM32 microcontroller system memory boot mode" and "AN3155 USART protocol used in the STM32 bootloader." They provide a "Flash Loader Demonstrator" at , which includes both a GUI and command-line version.

Works fine. I don't believe that the "Demonstrator" license permits redistribution but the protocol is well documented in the app notes and you have a known-working app to check against.

Poked around in the installation directory a bit. In addition to the documentation, ST also provides a couple of MS Windows DLLs with hooks for useful things like get_ID, read, upload, etc. as well as an example Visual Studio project. Looks like it's the complete source for the Flash Loader Demo. (I refuse to install Visual Studio so I haven't checked these out personally.)

Careful, IIRC the PIC32 bootloader to which you refer is loaded into FLASH, not ROM. This requires programming the part prior use and chews up flash (which costs more than ROM).

Sorry if new PIC32 have this in ROM, the ones I've used do not...

Hope that helps, Best Regards, Dave

PS: We're using LPC11C14 which has both serial and CAN bootloaders in ROM (though I never did find the CAN protocol).

Yes, it takes up 8K out of 512K flash, Our app takes around 100K, so it won't be a problem with space. Also, we load the app in high flash, and the bootloader is prohibited from changing low flash.

It's possible if you buy 100Ku+. But until then, they can preload the code in flash on the chip.

Have a look at Atmel SAM3 and SAM4 devices.

Writing my own bootloader would not be a problem - I've done it on many different micros, and as you say you can choose your interface and your protocol to suit. But that still means we have to use something else to get the bootloader into the chip in the first place - such as the EZ Port or JTAG. If I can find a family that has a suitable bootloader already in ROM, it would make production and test easier and faster.

I'll look into the LPC families.

David

The manufacturer can pre-load the bootloader on the chip, before sending to the PCB assembly house.

Oh, sure. We use openocd at the moment, this can be scripted for automation but I have not done this yet since our testing is still a manual process.

Interesting, Freescale still uses EzPort?

Their Coldfire V2 had it, but I didn't find any suitable "off the shelf" programming hardware, do you know any?

Regarding your question: I don't know, since SWD is the way to go for me. But if USB would be an alternative, there are derivatives with a USB bootloader in ROM, LPC13xx (likely many more).

I think, in a PC-Environment USB is simpler to manage today than UART.

Oliver

Not really, especially if you want to use USB in your app, then it becomes difficult to manage. For example, we wire it for USB host and it would be a headache to switch between the boot loader and app. For the PIC32, there are six UARTs, so we don't need to share.

BTW, you can always use USB to UART converter for PC/laptop.

snipped-for-privacy@gmail.com wrote

a config switch seems to be no more effort than a second serial connector.

I consider the PC side being the "problem".

Not that funny.

BTW: Please limit your line length to 70 characters in usenet postings.

Oliver

Have also a look at the STM32. They all have USART Bootloader in ROM, many parts also DFU bootloader. On F2/3/4 and L1, you can also reach the bootloader without setting the boot pins by using SYSCFG_MEMRMP and doing a core-reset (no system reset!).

Bye

That's a possibility we will certainly consider. In practice, it is more likely that we would get the distributor, rather than the manufacturer, to pre-program the devices before we mount them. Most big distributors offer such services - it's just a question of balance of convenience, price, delivering times, order quantities, etc.

If we decide to use the JTAG for programming, then OpenOCD will certainly be the basis. I expect that the EZ Port will be easier and faster (if we stick to Kinetis), however.