Messages

Thank you all for the responses. i'm still going over them and looking at documentation but in general it is becoming more clear.

2) the "fiddle the pins" can be implemented as an external circuit, then you do not need copy it on each and every board you make.

Thank you for the idea, and it does make sense for an engineering oriented end-user. However, the firmware upgrade method i would like to implement on my board is one in which the (non-technical) end user doesn't need to buy extra cables or equipment and doesn't need to take the final product apart in order to reprogram the LPC935 microcontroller. It should be done transparently through the USB microcontroller interface (acting as a bridge) along with the proper PC-based software. Thus i would like to find a minimal cost way (in terms of BOM cost) to make the firmware update as easy and transparent as possible, as well as robust and error-immune as possible. This means i should do all the hard work at the beginning in the design phase so that the end user will not really have to work so hard or be technically inclined in order to upgrade or update the firmware. It should be extremely simple and foolproof.

As i see it at this moment in time, although the ISP method is the easiest and the LPC935 chips come already preloaded with the ISP bootloader from the factory, and even though if i implement the NoTouch method, there is still that slightest of possibilities that if there is a power failure at the end-user's location during firmware update, the LPC935 will be dead and the end user will need to ship the product back for rework, which is not a pleasant thought and is expensive. Therefore, it seems that the most robust way of doing things is to use ICP and the extra hardware.

Since i can use the USB micro as an ISP-ICP bridge, all i need to do, theoretically, is to implement the Vdd powerdown of the LPC935, because the Reset pulsing and any other pin toggling on the target LPC935 can be done strictly via firmware in the bridge micro (plus some very minimal external components), instead of using all the external gates and other logic shown typically in something like the MCB900 schematic. Is this correct? All the literature i've seen so far regarding ICP programming always includes external circuitry attached to an RS232 level converter (eg: MAX232) to generate the proper ICP hardware timings via the host's serial port. This implies (i haven't investigated it yet) that Flash Magic creates the basic timings in the COM port signals which are massaged further by the on-board ICP programming logic. Is this also correct? Then my next question would be: would ISP-ICP bridge firmware do all of the signal conversion needed in the brdge micro's firmware only, by toggling some pins, without resorting to any RS232 level converter chip?

Finally, i haven't been able to figure out if Flash Magic can be used with USB. i assume it can, since Flash Magic has an "interface" setting and one of those is FDI USB. Am i correct or is it more complicated than that?

Does it look something like:

Flash Magic -> PC USB (FDI?) -> USB micro bridge firmware and pins -> LPC935 (with external power control component only, no other logic) ?

Is there any bridge micro firmware available for this particular architecture? Is there a Flash Magic DLL that i can get that i can incorporate into my own PC software?

Thank you for your patience. i know i've asked too many questions already...

OK, so what i am getting is that NoTouch is only for ISP but then there is no need for power cycling the Vdd and playing with the reset, etc., BUT there could be issues if the NoTouch is not programmed correctly the first time and something goes wrong, in which case it's time to solder a new chip in.

On the other hand, the advantages / disadvantages of ICP are that because it is hardware driven, there is no issue with the LPC9xx getting into a curare-like paralysis state BUT there is all that extra hardware to deal with.

i won't even attempt to figure out IAP...

Is this about right?

Moreover, ISP uses the TxD / RxD pins whereas ICP uses P0.4 and P0.5 (plus the power and Reset). There has been mention made of bootloaders for both ICP and ISP. Is this correct or ? Just to be clear, does the bootloader code go into the target LPC9xx as a set of routines alongside the firmware used for the embedded application (ie: the code i write)?

Finally, i still don't understand the issues with using the bootloader: is it used to provide a ISP front-end to be able to program the micro via Flash Magic? Is it also used for ICP? If i am using my own "bridge" microcontroller via USB, then can Flash Magic still be used or do i need to write my own PC-based code?

Sorry for so many questions. i think that Philips might have done a much better job if they had settled on one programming method for their microcontrollers and developed it properly, with REAL information and detailed examples on how to program the FLASH instead of having the information scattered to the four winds. As it is, there is too much confusion (especially for me) and it is taking much too much time and energy to figure all this out. It shouldn't have to be this difficult.

Perhaps a different microcontroller would be better suited and easier to program? (not necessarily Philips...)

Thanks again.

Hi Andy and Je,

Thanks to both of you for your input and also appreciated is your time spent for the reply. 

Your descriptions of the ICP and ISP are appreciated. Since i will already have a main microcontroller (with USB I/F) on the board which can be used as the ICP bridge micro, it seems at this point that ICP might be the best way to go.

Regarding the Vdd: i understand that the Vdd will need to be at the required voltage and stable for any operation, including programming, to occur properly but i have seen in a few app notes that the Vdd to the LPC935 (or LPC9xx) seems to need some kind of switching of Vdd for programming to proceed in ICP mode. Is this an absolute requirement? Must the Vdd be toggled On / Off in order to successfully program the 935 or is there a "trick" that can be used that allows the Vdd to be on and stable throughout the ICP programming?

Also, regarding using the MCB900: since i am architecting this board as well as designing the hardware and writing the firmware, my concern is to have the 935 programmed via the main USB micro through the USB port. i do not want the end-user to have to buy or have any special programming hardware in order to program the LPC935, so i don't want to use the MCB900, except maybe in initial debug of the first prototype, where it may be helpful.

Finally, thanks for the info on where to find the IAP bootloader source code. Is there similarly any bootloader source code for ICP?

Thank you. 

Hi,

What do you mean when you say that NoTouch does not have "the words"? Which words are you referring to, please?

Thanks.

Thanks, Andy, for the information. i have more questions though...sorry for the trouble:

* Does ICP also require that the Vdd on the 935 be controlled?

* Is there a schematic that is known good to use for ICP hardware for the 935 and where can i look at it, please? (i already have a few app notes and schematics but i'm not sure which one is the latest / most accurate)

* In my proposed system architecture (using a second USB microcontroller and I2C), are you saying that by using IAP and my own bootloader that it would be a better solution than ICP (or can i also use ICP via I2c?)?

* Are there any examples of IAP-based and ICP-based bootloader source code to look at or download?

* i would prefer to do the firmware programming / updates via my own Windows-based code. Is there any place i can download a code example or demo project for Windows to do this?

* Finally, what are the worst-case potential problems with using either IAP or ICP? eg: the LPC935 getting into a state that would require unsoldering the device and using a parallel programmer to recover it. Or does using IAP or ICP prevent this?

Again, sorry for all these questions. i'm very new at using the Philips parts and in the way they do the in-system programming. i've been downloading all the data sheets and application notes i can find, plus looking at a few forums but i'm getting more confused the deeper i look. It would be nice to get enough reliable information that says "you are >HERE<".

Any help or insight is most deeply appreciated. Thank you.

Hi,

i am planning on using an 89LPC935 as a "subprocessor" in my project, ie: there's another main processor on the board that talks to USB and  then it talks to the LPC935 via I2C. What i'd like to be able to do is to somehow use the main processor to program the LPC935 with new code so that the end user doesn't need cables or special programming hardware to update any LPC935 firmware. Ideally it should be done through the USB connection and main processor with the programming routines residing in the PC or the main processor. i've been trying to understand all the nuances of the different programming schemes for the LPC935 (LPC9xx), ISP, IAP and ICP but it is all very confusing and seems very prone to error, different chip revisions, etc. and, worst of all, with the prospect of an incorrect programming attempt requiring the replacement of the LPC935 chip on the PCB which would be unacceptable.

Before i commit to using the LPC935, i'd like to get a solid enough understanding of and feeling for a robust method of LPC935 programming / updating of firmware with minimal added hardware resources and a method that best suits the scenario i described above. Can anyone please explain how this might be achieved or even if it's possible?

For example, in the ICP method, if i understand it correctly, the programmer must control the Vdd to the 935 for programming, which complicates the hardware and adds expense. Do ALL the various programming methods need to control Vdd or do ISP and IAP not need this?

Thanks in advance.