On 06/10/13 13:36, Uwe Bonnes wrote:> David Brown <david.brown@removethis.hesbynett.no> wrote: > >> I'll look into the LPC families. > > 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 >OK, that's another one on my list to investigate. Thanks!
Cortex M3/M4 with bootloader ROM
Started by ●October 4, 2013
Reply by ●October 6, 20132013-10-06
Reply by ●October 6, 20132013-10-06
On 05/10/13 11:07, Oliver Betz wrote:> David Brown wrote: > >> 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 > > 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? >I haven't seen anything off-the-shelf for EZ Port. But it's not hard to make one - I'll probably first start with an FTDI module (these things are /really/ convenient). It would also not be hard to make a dedicated programming board that supports parallel programming of lots of devices.> 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. >USB is great for in-field programming, as you can plug it into pretty much any PC. But it is not good for production programming - you usually need more complex software, and it is often Windows-specific which means painfully slow attachment and enumeration, and typically means you can only handle one board at a time on one PC. (With Linux its a lot easier, but only if your programming software works on it.)
Reply by ●October 6, 20132013-10-06
Mikko Syrjalahti <first.last@iki.fi> writes:> Unfortunately I could not find manual for the protocol, but it must be > available somewhere..Got it. UM10360, chapter 32 has the LPC17xx bootloader documentation! The programming code is about 500 lines of python in our case. -- mikko
Reply by ●October 6, 20132013-10-06
David Brown wrote:> USB is great for in-field programming, as you can plug it into pretty > much any PC. But it is not good for production programming - you > usually need more complex software, and it is often Windows-specific > which means painfully slow attachment and enumeration, and typically > means you can only handle one board at a time on one PC. (With Linux > its a lot easier, but only if your programming software works on it.)At least with the LPC11U37 (Cortex-M0) which I'm using, it is very easy: If there is no valid user code already flashed, the bootloader provides a mass storage interface for Windows, and you can just copy the firmware file to it for flashing it. No need for special software, like SAM-BA for Atmel devices, which in my experience didn't work reliable all the time, especially on Windows 7 64 bit systems. Enumerating and flashing is very fast (I can see the USB drive a second after connecting to the PC and flashing needs another 2-3 seconds), so no problem to do it for one device at a time, only. If there was already a firmware flashed, you have to ground a pin during reset to start the mass storage part again. I guess the Cortex-M3 LPC17xx parts have the same feature. -- Frank Buss, http://www.frank-buss.de electronics and more: http://www.youtube.com/user/frankbuss
Reply by ●October 7, 20132013-10-07
On 06/10/13 22:02, Frank Buss wrote:> David Brown wrote: > >> USB is great for in-field programming, as you can plug it into pretty >> much any PC. But it is not good for production programming - you >> usually need more complex software, and it is often Windows-specific >> which means painfully slow attachment and enumeration, and typically >> means you can only handle one board at a time on one PC. (With Linux >> its a lot easier, but only if your programming software works on it.) > > At least with the LPC11U37 (Cortex-M0) which I'm using, it is very easy: > If there is no valid user code already flashed, the bootloader provides > a mass storage interface for Windows, and you can just copy the firmware > file to it for flashing it. No need for special software, like SAM-BA > for Atmel devices, which in my experience didn't work reliable all the > time, especially on Windows 7 64 bit systems. Enumerating and flashing > is very fast (I can see the USB drive a second after connecting to the > PC and flashing needs another 2-3 seconds), so no problem to do it for > one device at a time, only.That sounds like a nice way to handle flashing, so I'll look into this one. For in-field updates it would work very well - and it's not hard to connect a pin to ground for programming mode. It would be useless for production programming with Windows because it could not be sensibly automated or scaled, but unless the designers have done something /really/ weird it will work fine with Linux where these things can be automated well.> > If there was already a firmware flashed, you have to ground a pin during > reset to start the mass storage part again. I guess the Cortex-M3 > LPC17xx parts have the same feature. >
Reply by ●October 7, 20132013-10-07
David Brown wrote: (LPC11U37 USB mass storage device)>That sounds like a nice way to handle flashing, so I'll look into this >one. For in-field updates it would work very well - and it's not hard >to connect a pin to ground for programming mode. It would be useless >for production programming with Windows because it could not be sensibly >automated or scaled, but unless the designers have done somethingWhere do you expect problems Oliver -- Oliver Betz, Munich despammed.com is broken, use Reply-To:
Reply by ●October 7, 20132013-10-07
On 07/10/13 09:55, Oliver Betz wrote:> David Brown wrote: > > (LPC11U37 USB mass storage device) > >> That sounds like a nice way to handle flashing, so I'll look into this >> one. For in-field updates it would work very well - and it's not hard >> to connect a pin to ground for programming mode. It would be useless >> for production programming with Windows because it could not be sensibly >> automated or scaled, but unless the designers have done something > > Where do you expect problems > > Oliver >When you plug a USB memory stick into windows, you get a few seconds pause, then Windows picks a drive letter for the new drive, and opens an explorer window for the device. If you are working manually, that's fine - you can just drag-and-drop the update file into this window. Then you select "safe eject" from the right-mouse menu for the drive. But for automated parallel programming of multiple cards at a time, this cannot work - there is no person looking at windows, and doing drag-and-drop. For automated programming, you need to know which card corresponds to which "drive", you need to be able to see when they are attached, start and track the copy, and then unmount the drive - all without any windows popping up or user intervention. It is conceivable that this /can/ be done with Windows - but it would be a long, difficult and inelegant process. Contrast this with Linux. Here I would set up a USB hub (or hubs, as necessary), and make some udev rules that triggered for new "drives" and gave the drive a dedicated name dependent on the USB hub slot. The udev rule would trigger a small script to mount the drive, copy over the program, record the details in a database, and unmount the drive. That's perhaps a couple of dozen lines of Python script, on a headless machine (a couple of LEDs on the board is all the interface needed) - scalable to as many parallel connections as we want.
Reply by ●October 7, 20132013-10-07
David Brown wrote:>> (LPC11U37 USB mass storage device) >> >>> That sounds like a nice way to handle flashing, so I'll look into this >>> one. For in-field updates it would work very well - and it's not hard >>> to connect a pin to ground for programming mode. It would be useless >>> for production programming with Windows because it could not be sensibly >>> automated or scaled, but unless the designers have done something >> >> Where do you expect problems > >When you plug a USB memory stick into windows, you get a few seconds >pause, then Windows picks a drive letter for the new drive, and opens an >explorer window for the device. If you are working manually, that'snot on any PC I work with or I help maintaining.>fine - you can just drag-and-drop the update file into this window. >Then you select "safe eject" from the right-mouse menu for the drive. > >But for automated parallel programming of multiple cards at a time, thisI don't know how fast the available "USB boot enabled" controllers are, but if programming is (nearly) as fast as I plug devices, why should I program more than one device at a time?>cannot work - there is no person looking at windows, and doing >drag-and-drop. For automated programming, you need to know which card >corresponds to which "drive", you need to be able to see when they arehttp://www.uwe-sieber.de/usbdlm_e.html should do this. After all, I would prefer other USB classes, e.g. HID. But I can't tell you whether that's available in ROM on any device. Oliver -- Oliver Betz, Munich despammed.com is broken, use Reply-To:
Reply by ●October 7, 20132013-10-07
On Monday, October 7, 2013 7:20:46 AM UTC-4, David Brown wrote:> When you plug a USB memory stick into windows, you get a few seconds > pause, then Windows picks a drive letter for the new drive, and opens an > explorer window for the device. If you are working manually, that's > fine - you can just drag-and-drop the update file into this window. > Then you select "safe eject" from the right-mouse menu for the drive. > > But for automated parallel programming of multiple cards at a time, this > cannot work - there is no person looking at windows, and doing > drag-and-drop. For automated programming, you need to know which card > corresponds to which "drive", you need to be able to see when they are > attached, start and track the copy, and then unmount the drive - all > without any windows popping up or user intervention. It is conceivable > that this /can/ be done with Windows - but it would be a long, difficult > and inelegant process.Um, unless I'm missing something, that should be a pretty easy script even in Windows, or a C# program... Hope that helps, Best Regards, Dave
Reply by ●October 8, 20132013-10-08
On 07/10/13 15:50, Oliver Betz wrote:> David Brown wrote: > >>> (LPC11U37 USB mass storage device) >>> >>>> That sounds like a nice way to handle flashing, so I'll look into this >>>> one. For in-field updates it would work very well - and it's not hard >>>> to connect a pin to ground for programming mode. It would be useless >>>> for production programming with Windows because it could not be sensibly >>>> automated or scaled, but unless the designers have done something >>> >>> Where do you expect problems >> >> When you plug a USB memory stick into windows, you get a few seconds >> pause, then Windows picks a drive letter for the new drive, and opens an >> explorer window for the device. If you are working manually, that's > > not on any PC I work with or I help maintaining.I guess it's been a long time since I plugged a USB stick into a windows machine - I use Linux for most of my work and play. No window opens automatically, but the drive letter does get picked from the next letter Windows thinks might be available. The utility you mentioned below could make this a bit more controlled and consistent.> >> fine - you can just drag-and-drop the update file into this window. >> Then you select "safe eject" from the right-mouse menu for the drive. >> >> But for automated parallel programming of multiple cards at a time, this > > I don't know how fast the available "USB boot enabled" controllers > are, but if programming is (nearly) as fast as I plug devices, why > should I program more than one device at a time?Automated production programming often needs to handle things in parallel, even if the programming time is short. Keeping production costs down is all about getting more work done in fewer man-hours. So if you can attach a panel of 8 cards to your programming system at once, rather than individually, you reduce your costs.> >> cannot work - there is no person looking at windows, and doing >> drag-and-drop. For automated programming, you need to know which card >> corresponds to which "drive", you need to be able to see when they are > > http://www.uwe-sieber.de/usbdlm_e.html should do this. > > After all, I would prefer other USB classes, e.g. HID. But I can't > tell you whether that's available in ROM on any device. > > Oliver >
