Reset after success remote update

You managed to update your fw. If the verify passed, then you know that the copy operation worked.

But that isn't a guarantee that the firmware you downloaded is correct. If you download a buggy firmware, your board may fail to start.

In this case you are not supplying any information at all that can help us help you with your problem.

We don't know what equipment you have updated. We don't know what the old firmware was. We don't know what the new firmware is. We don't know if it is an application that you have written/modified, or if it is a demo application.

We don't know what indications you are looking at to deduce that the firmware doesn't run now but did run before the update.

You managed to update your fw. If the verify passed, then you know that the copy operation worked.

But that isn't a guarantee that the firmware you downloaded is correct. If you download a buggy firmware, your board may fail to start.

In this case you are not supplying any information at all that can help us help you with your problem.

We don't know what equipment you have updated. We don't know what the old firmware was. We don't know what the new firmware is. We don't know if it is an application that you have written/modified, or if it is a demo application.

We don't know what indications you are looking at to deduce that the firmware doesn't run now but did run before the update.

Hi,

I am using uVision 3 with ulink2 and the target is in house development. The new FW is a simple one that sends string to the UART (It is working with direct download using ULINK2). I verified that the new FW image is identical to the original with the help of ULINK2 and uVision3 (Option for target --> utilities --> settings --> verify).

And after reset, I notice that the controller (LPC2136) do not return from the internal bootloader.

I hope I supply enough information (If not I will add more).

Thanks Kobi

A bootloader you have written, or the NXP bootloader built into the chip?

The NXP boot loader checksums your interrupt vector table before deciding if there is a program to start. If the checksum is wrong, and you haven't activated any code-protection features, then the built-in boot loader will just sit and wait for a download program to connect and start sending commands.

Hi,

This is NXP internal bootloader

TNX Kobi

Hi,

It looks that the bootloader is in endless loop.

I checked with ULINK2 that it is my new FW, so why it is do not copy the VIC to address 0 and start the new program?

TNX Kobi

Hi,

As I wrote before, I managed to burn my new FW instead of the old one, but the new FW is not restarts.
I checked That the new FW is correct (Validate it with ULINK2). As far as I understand, the bootloader checks if the program signature is valid.
My new FW is stuck at the LPC bootloader and do not run the new FW(probably because the program signature is wrong).

Is the program signature is included with the INTEL hex file?
If no, how do I updates it?

Please advice Kobi

The Keil tools will automagically create a checksum for the interrupt vector table. As long as you download that address range, the NXP boot loader should be able to sum all vectors and get a total of zero. This indicates that there is an application loaded, and the NXP boot loader will then start your firmware.

If your download doesn't contain the interrupt vector table - or downloads it to the wrong address - the NXP boot loader will (as intended) wait in an infinite loop for anyone to connect on the monitor port and feed it a new firmware.