LPC2200 series bootloader implementation process:

There are similar implementation methods on the Internet. There is one provided by NXP, which is easy to obtain. You can download the latest version on the LPCware website. Relatively speaking, this is also a relatively complete project. There is also ZLG's AN070701. I took a look and it seems that BOOT and application are in one project. This is not suitable for me. I want to make two independent projects, one BOOT and one APP. However, the principles of the above methods are the same. In addition, there are many transplants made by netizens on the Internet. I also downloaded some and saw that most of them directly or indirectly used NXP or ZLG's solutions. After comparison, I decided to use the NXP example.

The principle of bootloader is that after boot is started, it first determines whether there is firmware that needs to be upgraded from the serial port. If so, the firmware is downloaded through the serial port. After the download is completed, the firmware is burned to the 0x00010000FLASH address through IAP, and then jumps to the 0x00010000 address to execute the application.

The basic principle is the same. If you understand the principle, you can easily start the application from the network port or the SD card. The whole transplant process was smooth and unexpectedly smooth. After I transplanted the serial port receiving and sending functions, I could use it soon. However, I was not satisfied with the blocking mode of the serial port receiving and sending of the "official BOOT", which seemed to be very backward. I used the non-blocking receiving and sending mode on LPC1788. However, the official BOOT function is more complete, and there are several commands, which are good to use.

After using it for half a month, I suddenly found a very hidden problem. When I added a second network port to LPC2294, it crashed from time to time. The unit also tracked it, but still couldn't find the problem. After searching on the Internet, I found that several people encountered similar problems, "After starting the application through a custom BOOTLOADER, it crashed from time to time." The phenomenon was similar. Some of them crashed in printf(), and mine crashed when adding a second network port driver; but there was a common point that "custom BOOTLOADER was used". The process of locating the problem was "painful and long". First of all, I made sure that there was no problem with my application: I directly burned my application to the address 0X00000000, started the board, and there was no crash. From this, I basically concluded that there was no problem with my application.

But the problem was basically locked on BOOT, but BOOT is officially provided, so there should be no problem. Since I have used it, I rarely doubt the official programs provided online. For a company like NXP, I can only learn from it. So I followed the solution of a classmate online, filled the FLASH space in the range of 0X00000000-0X00010000 with 0x00, and re-burned the application at 0X00010000 (Note: the interrupt vector table should also be copied to SRAM (0x40000000)). For a long time, I suspected that there was something wrong with the interrupt vector table. After the board is powered on, the 64k NOP instruction is executed first, until the application program of 0X00010000. There is no problem in this test, which means that there is no problem in remapping my interrupt vector table to SRAM. In this way, it can be basically judged that the problem is caused by BOOT. The above ideas are basically the ideas of netizens, and the Internet stops here. I did it here, and suddenly I had an inspiration. Is there a problem when boot jumps to app? I tested it immediately and found the problem. When power-on reset, the LPC2294 kernel is in SVC state, and when BOOT jumps to APP, it is in USR state. In this USR state, many register operations are invalid, and the comparison design stacking and other operations are invalid. Finally, the first section of assembly code of APP is not executed correctly, which lays the groundwork for the subsequent unscheduled crash! !

I am really happy to find this error which is so hidden and difficult to understand. Thanks to the netizens for doing so much research.

Once again, God always favors me when I am about to give up! !