Cortex M3/M4 with bootloader ROM

Does anyone have recommendations for Cortex M3/M4 microcontrollers with a bootloader in ROM? We use a number of Freescale Kinetis devices, but there is no ROM bootloader - programming is through either JTAG or the EZ-Port (basically treating the chip like an SPI flash device). We have an application where a UART-based bootloader would be very useful, and having it in ROM would save a lot of effort and production time (like the TI msp430 microcontrollers). There are vast numbers of M3/M4 devices available - I am looking for recommendations for ones with a simple and clear bootloader protocol.

Thanks,

David

Reply to
David Brown
Loading thread data ...

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

--
Mikko
Reply to
Mikko Syrjalahti

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

formatting link

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

--
Grant Edwards               grant.b.edwards        Yow! We are now enjoying 
                                  at               total mutual interaction in 
 Click to see the full signature
Reply to
Grant Edwards

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.

Reply to
edward.ming.lee

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.

--
Chisolm 
Republic of Texas
Reply to
Joe Chisolm

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.

--

John Devereux
Reply to
John Devereux

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.

Reply to
Rich Webb

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

Reply to
Rich Webb

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

Reply to
Dave Nadler

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.

Reply to
edward.ming.lee

Have a look at Atmel SAM3 and SAM4 devices.

--

Tauno Voipio
Reply to
Tauno Voipio

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

Reply to
David Brown

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

Reply to
edward.ming.lee

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.

--

John Devereux
Reply to
John Devereux

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

--
Oliver Betz, Munich http://oliverbetz.de/
Reply to
Oliver Betz

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.

Reply to
edward.ming.lee

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

--
Oliver Betz, Munich http://oliverbetz.de/
Reply to
Oliver Betz

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

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de 

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt 
 Click to see the full signature
Reply to
Uwe Bonnes

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.

Reply to
David Brown

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.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.