We have a mature product in production using the NXP LPC2468. We bring the first UART out to an RS-232 driver along with RESET and the pin for the on-chip bootloader. On a PC, an FTDI cable for RS-232 to USB is used with FlashMagic to download the HEX file. The product has 8 serial ports, 4 internal to the chip, 3 RS-485 ports in addition to the first RS-232 port plus an additional 4 RS-485 ports connected to a QUAD UART on the board. We connect a box with 2 buttons (one reset, one bootload), the FTDI cable, and the USB connector for bootloading.
To bootload, I press and hold the bootload button while momentarily pressing the reset button. I use FlashMagic to connect to the virtual COM port on a laptop and download the HEX file.
This method works wonderfully, over and over again.... unless it doesn't work.
On only one of our boxes so far, I cannot get the processor to enter bootload mode. On several others, I need to disconnect the other RS-485 ports before bootload mode worked. This leads me to believe there's some interaction on the ground or perhaps the processor sees data on another UART which is tricking it out of using the first port.
Has anyone seen bootloading issues using the built-in bootloader on this or similar processor which could be attributed to a hardware layout?
Is the reset circuit on the design robust? ie hold and maintain it for ~100-200ms, reset when supplies out of spec Are there external pull up resistors on the RESET and BOOTLOAD pins (assuming negative asserting)? Are there capacitors on these same pins? Are these pins driven by any push-pull drivers in your circuit?
What do these signals look like on failing units?
There is a 10k pull-up to 3.3v on the reset line with a 10uF cap to ground. In addition, there is a 10k pull-up on the Bootload pin to 3.3v Nothing else is connected. These signals come out to an external connector. The signals are controlled only by two mechanical push-button switches to ground, which is only hooked up to facilitate the bootloader function then are disconnected during normal operation.
I have not yet looked at the signals with a scope.
The chip should 100% ignore anything happening on any other serial port.
In your case, you have no real reset supervisor chip but just using a resistor + capacitor. That means your circuit is sensitive to switch bounces from a mechanical switch that can create out-of-spec reset pulses.
The only other issue that I can see is that the chip fails to auto-baud, because it is initially using the internal RC oscillator. After it has auto-bauded and received a message telling it what external crystal oscillator that is connected, the boot loader in the chip can later switch to the crystal oscillator for the rest of the operation.
I have seen the failure to autobaud message. While in FlashMagic, I open the terminal window and see the application code boot rather than the bootloader.
Since it appears to bootload more reliably with the other RS-485 connectors disconnected, I will investigate a weak or noisy ground on the bootload pin.
Thanks.