Messages

I've already discussed this with Andy personally, but I figured I'd post it here, too, to see if there was any interest.  With the existing ISP-ICP bridge solution you need to move jumpers on the MCB900 to switch between programming the bridge MCU and programming the target MCU.  If there were an option to strobe DTR to cycle power to the bridge MCU without strobing RTS/RXD to toggle the bridge MCU reset, you could program the target MCU without having to shunt the bridge MCU power or open it's reset line (i.e. you could leave the jumper in the same position used to program the MCU on the MCB900).  This may or may not be of much practical use on the MCB900, but we have a production test fixture with an integrated ISP-ICP bridge MCU (basically a copy of MCB900) and it would be great to be able change between updating the firmware in the bridge MCU (or even program it the first time) and programming target MCUs without having to do anything to the hardware.

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.

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

Thanks!  It works well.

See my related post here for a follow up:
http://forum.flashmagictool.com/index.php?topic=3532.msg4464#msg4464

Ok, so I'm an idiot.    I had the reset and ICP PCL signals swapped in my connector.  Doh!  It seems to mostly work fine now.  It would still be nice to have "official" support of the 89LPC9381, though, because the ISP code is in a different location than on the 89LPC938, so I'm not sure the "protect ISP code" works correctly.  Does that option actually read the boot vector and status bits from the device to determine which flash block to "protect" or does it use a hard-coded location per device (i.e. 0x1C00-0x1FFF for '938)?

By the way, the device signature for the 89LPC9381 is:
Manufacturer ID: 0x15 (Philips/NXP)
Device ID 1: 0xDD
Device ID 2: 0x2A

This is supposedly just a P89LPC938 with half of the flash removed and several of the peripherals removed (CCU, EEPROM, XDATA ram, etc.) to reduce cost.  I haven't been able to get any information yet from my FAE regarding the device ID / Signature, but I just asked.  If there's anything I can do to help, let me know.  It would be awesome if the program were user-extensible to add devices via some sort of device definition file, but as long as your willing to keep up your awesome level of device support, I guess that's not necessary!   

Hi Everyone,

Has anyone had any success with ICP on the P89LPC9381?  I am using the USB-ICP programming adaptor and a custom PCB with the P89LPC9381 on it.  Neither UCB-ICP nor FlashMagic seem to "officially" support the P89LPC9381, but an NXP FAE told me that I should be able to just treat it as an P89LPC938 with half of the flash blocks and a few less peripherals, since that's basically what it is.  I tried this, though, will no success.  FlashMagic complained that the ID bytes didn't match (which is to be expected, since it's not *actually* a '938), but erased the device anyway with apparent success.  When I attempted to read the device signature manually, it returned all 0s.

Any ideas?