Content originally posted in LPCWare by hangdog on Sun Aug 24 06:17:30 MST 2014
Hi
I've been developing a project for LPC4330 for some time, and all is generally going well now. As the project nears completion, it's time to think about providing a facility for reflashing the device in the field, if (ok, when) the need arises. I wonder if anyone is able to give me a steer on what the path of least resistance might be in that regard.
This device is flashless, and has an external FLASH chip (SST39VF801) attached. The product will use the USB0 port to communicate with the wider system, so that gets configured using the ROM-provided drivers to offer an MSC class interface, during startup. So, it'd be nice if the flashing could take place through the same USB port. Attaching a PC to that interface would be fine; alternatively, having the device itself act as the host, and attaching a USB stick with the bin file on to that port would also be fine. Using an existing piece of PC software to do the flashing would be great, if such exists.
I'm aware that there is some support for in-system programming offered by the device ROM, too, but my reading suggests this must take place over USART, which is not ideal (see above). Chapter 6 of the user manual also covers "in application programming" (which sounds like my use case) but I can't grok what it offers. It also states "IAP commands are only supported for parts with on-chip flash", but then later "Some IAP commands are supported for parts with on-chip flash only", which seems ambiguous.
Perhaps the simplest for me to understand would be, since we're going to be offering an MSC interface over USB0 anyway, if part of that interface offered the option to write (parts of) the external FLASH through the device. So that's probably what I would try, if there are no other obvious options. But if the support offered in the ROM is suitable for what I'm trying to do, of course that sounds more attractive because it'll remove the possibility of us screwing up the reflash code and bricking our customers' devices.
If there exists a "standard solution" to this - or a sensible starting point for development - I'd obviously much rather not reinvent anything, with all the risks that would involve. Hence, I wonder if anyone is able to give me a steer?
Thanks in advance, Ben
