ISP to ICP works with everything but actually programming the hex file

[kittmaster]

I now have it setup as an ISP to ICP bridge with code version 1.7 from flashmagic.

I can read everything from flashmagic like the ICP target device sig, security bits, I can do everything.....except it won't program the hex file in. I'm using the same lpc936 so size isn't the issue, and the bridge is obviously working. If I pull the ICP device, I get all FF for device sig, put it back in, I get normal readback of data and configuration info.

I don't understand why it won't program. The app note says ensure dtr and rts is checked and to protect ISP. All of that's done.

Any ideas what I could be missing here? Its 99.4% ready, just the pesky problem of doing what its designed for.....<laughing to myself>

Thanks

[Werner]

Hi Kittmaster,

i discovered the same problem while working on the bootloader program.
The problem is that your chip in the ICP-bridge has an rc-oscillator with frequency of a little less than 7.3728MHz. Because the bootloader or the ICP-bridge has to echo every received byte, long records (used for programming) overflows the receiver at some time.

As long as the problem isn't fixed by software the only thing you can do is to try a number of chips in the ICP-bridge until you find one with a little faster oscillator. Then echoing is faster than receiving and your programming works.

Good luck
Werner

[erikm]

As long as the problem isn't fixed by software the only thing you can do is to try a number of chips in the ICP-bridge until you find one with a little faster oscillator. Then echoing is faster than receiving and your programming works.

what about just writing the TRIM

Erik

[Werner]

Hi Erik,

have you got the source code of the ICP-bridge software? Tell me where to get it. I'm looking for it for so long.
Then i would be able to write to TRIM or BRGR0 and 1.

[Andy Ayre]

Unfortunately the contents of TRIM are restored on reset, so this is really for configuration by executing firmware. I presume that the bootloader does not write to the TRIM register.

If you are seeing a deviation in the RC oscillator of more than 1% then you should contact NXP and let them know, because this would be a problem.

The sources for the ICP bridge are available on the resources page of the Flash Magic website:

  http://www.flashmagictool.com/resources.html

Andy

[BobSki778]

I was experiencing a very similar problem.  I was able to do everything but program a LPC9381 (the process would proceed to the "Programming..." state, but the status bar would not progress and eventually it would timout with the "Unable to communicate. (transmit/receive)" error).  I was, however, able to successfully program an LPC912.  I found that when I attempted to create a debug file (according to this post: http://forum.flashmagictool.com/index.php?topic=3272.0) that I was mysteriously now able to successfully program the LPC9381.  I sent an email to support about this.  My guess would be that enabling debug mode slowed something down to the point of working, would indicates a timing or buffer overflow issue.

Bob

[BobSki778]

OK, I spent a fair amount of time (maybe as much as a week) working with Andy at EAS and people at NXP, and the ultimate problem seems to be the tolerance of the RC oscillator in the MCU running the bridge firmware.  Even if it is still within NXP's spec of 7.373MHz +/- 2.5%, if it is on the slow side, and the host PC sends a burst of serial data with no "dead time" on the serial data line between bytes, then eventually the baud rate timing error will accumulate and UART in the bridge MCU will fall far enough behind that it will miss a start or stop bit and thus miss a data byte.

Solutions are:
- Using an 7.3728MHz external crystal instead of the internal RC oscillator and setting the chip configuration to use the crystal instead of the RC oscillator, or
- Modifying the bridge firmware to correct for baud rate error due to the RC clock tolerance (either by tweaking RC oscillator TRIM or the baud rate on a per-unit basis or by implementing "autobaud" rate detection).  The bridge firmware source code is not publicly available, though, so this means either having a good enough relationship with NXP that they'll let you have the source code or reverse engineering it from the HEX file.

Other possible solutions:
- It may also be possible that simply setting the UART baud rate intentionally high (so that it would be correct with the lowest possible RC oscillator frequency, 7.373MHz - 2.5%), but then if the RC oscillator is at it's maximum tolerance, the baud rate will be 5% faster than nominal, which may introduce other problems (though I think it should be fine, since the MCU will never burst data faster than the PC can handle it, because it speaks only when spoken too and is therefore paced by the rate at which it receives data from the PC), or
- Get EAS to modify FlashMagic to slow down the rate at which it sends data to a target device, but that doesn't seem practical, as timing of this nature would probably be very system dependent, and I personally would rather have EAS spend time adding functionality to FlashMagic rather than working around a flaw in the design of the ISP-ICP bridge firmware.

[Andy Ayre]

My recommendation at this point based on Bob's findings is to use an external crystal. It's a simple solution that should work for everyone.

Andy

[Je Gold]

1. The original ICP--> ISP  Bridge schematics have flaws  ... see the resources pages of the flashmagic web site.

2. For on going profesional development where... time is money... it might be better purchasing a profesional ICP programmers - such as the TEAM FDI one.

Joe

[rbtamd]

Hi folks

I solve this problem enabling the half duplex communication based on the Andy´s post on the "read this post before..."


3. If you have the half-duplex communications feature turned on and you do not need it, then turn it off. It only slows down the serial communications.

HTH

Roberto