We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi All,
I managed to update my FW, but the new FW is not start to work.
I checked that the new FW is burn correctly (I verify it with uVision3 with the verify option at the utility settings).
Please advice Kobi
Hi,
I am downloading the INTEL hex file without the JTAG.
From my understanding, the bootloader suppose to copying the interrupt vectors to address 0x0000.
I think that the INTEL HEX file do not contains the bootloader.
Is there any one that succeeded to update his FW that worked in the way that I am trying? If yes How? Is this the right way to do so? If not, what is the right way?
hi can you make elf files with the uvision?
No, the hex file does not contain the NXP boot loader.
Note that the NXP boot loader has its interrupt vector remapped to the start of the first flash sector, so blank-checking of comparing of the first 64 bytes of this sector using the ISP/IAP commands will fail.
I know that it is not contain the interrupt vector. The question is, why the new FW does not copy the vector interrupt to address 0x0000.
Is it the problem with the program signature? And how can I resolve it?
Kobi
How do you know that the new FW does not contain the interrupt vector table?
Finally, it is working!
The problem was that HEX file do not contains the program signature. I calculated the program signature and added it to the HEX file and it is working.
Thanks for the help
I am happy to know that you solve the problem. Actually, I got the similar problem. Hope that you can share your experience to me.
Well, I also try to use IAP to update my firmware on LPC2103. The system will connect with another main board via UART. Main board is master to send the updated firmware to LPC2103. Original, my idea is separate LPC2103 firmware as two parts; system base and application. The system base will locate at sector 0 with UART function and boot (ie. startup.s). And the application will locate at the remainder 3 sectors. When I want to update firmware, close the application and jump back to system base to receive updated code into RAM via UART. Re-warite the application and try to reboot. The whole system crash. After compare the on-chip ROM code with the new updated code found the system base is different. I did fix the application entry by use __at commend. Unfortunately, the system base can not be fixed. I found the KEIL will increase some object code which maybe my application use new function in it. Could you understand my problem? Here is my scatter file to separate the system base and application. Maybe you can help to solve it.
======================================= LR_IROM1 0x00000000 { ; load region ER_IROM1 0x00000000 0x00001000 { ; load address = execution address *.o (RESET, +First) main.o (+RO) iap.o (+RO) uart.o (+RO) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x40000000 0x00001000 { ; RW data .ANY (+RW +ZI) } }
LR_IROM2 0x00001000 0x00003000 { ER_IROM2 0x00001000 0x00003000 { ; load address = execution address menupage.o (+RO) key.o (+RO) lcdDisplay.o (+RO) Ultrasonic.o (+RO) Diagnostic.o (+RO) led.o (+RO) app_main.o (+RO) utility.o (+RO) NormalUart.o (+RO) lcd.o (+RO)
;.ANY (+RO) } } ==============================
Kindly, please advice.
Thanks, Dennis
Hi Dennis,
Try to look for the program checksum.
At address 0x14 at the startup code, the FLASH device (ULINK2) add the program cs.
Basically, if you downloaded new FW, the cs was changed and the startup code has the old cs.
I changed all my application include the startup code. (I had to add the CS value to the HEX file with additional external application, the Philips old version of ISP).
Regards Kobi
Hi Kobi,
Thanks again.
I have a little confuse. I'd checked the address 0x14, it should be and interrupt vector (VicVectAddr) in my startup.s, like below.
//Startup.s Vectors LDR PC, Reset_Addr LDR PC, Undef_Addr LDR PC, SWI_Addr LDR PC, PAbt_Addr LDR PC, DAbt_Addr NOP ; Reserved Vector ; LDR PC, IRQ_Addr LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr ////////
I know how to write flash by IAP function. Actually, I don't know how to write a program to update entire flash, so I separate my image to two regions. And hope the boot region is fixed (but not). I found the problem might happen in __user_initial_stackheap() or __user_setup_stackheap(). Because KEIL will add them if I don't override them. Similar, if my application use the new function that need C library. KEIL compiler will increase the C library into my boot region since my scatter.
However, if I can know how to re-write the entire flash in runtime, I don't need to care the KEIL compiler did. Can you show me how?
Best Regards, Dennis.
In order to update all the FLASH you need to run your IAP functions from the RAM.
After you receive you new FW image, and you decide to burn it, your application should run a routine from the RAM that will erase all the FLASH and will burn the new one instead of it. Obviously you should save the new FW at external FLASH or save it at the upper addresses of you controller and therefore erase only half of the controller.
In my case, I received the new image to external FLASH, then parse it and copy it to the upper controller addresses and as soon as the new FW is at the controller, I run routine from the RAM in order to copy it from the upper addresses to the lower one. This architecture can be more efficient (copy it from the external FLASH directly to the lower controller addresses) but the first one requires less code in the RAM.
In addition you have to add the checksum to the new image at address 0x14. The old ISP application of NXP add the checksum to the code.