I am trying to write a customized boot loader application on LPC2478. The bootloader application reads the hex file stored in a memory device and programs the on chip flash memory using IAP routines. the test application resides at location 0x60000. After the chip programming is complete the bootloader is supposed to jump to 0x6000 using "(*((void(*)(void))0x60000))();"
The problem i am facing is 1>. Even though the bootloader successfully programs the flash 0x6000 onward, which i have read using flash magic, the application refuses to start.
2>. I have no clue of what to do with record types "01" and "05" which i have encountered in my hex files.
3>. If i program the same hex file that i programmed using my bootloader using flash magic [both bootloader and hex file resides at this time] , the application runs successfully.
4>. I tried to read the entire chip memory [0x0000 to 0x7DFFF containing boot loader and test application both] using flash magic and saved to a file then re-programmed using flash magic, and the same test application runs. A>. kindly someone let me know what is to be done when record type 01 and 05 is encountered.
B>. Is there some sacred data that is to be written on chip after which the bootloader operation would be considered complete so that an application runs.
in the above 0x6000 is actually 0x60000 1>. Even though the bootloader successfully programs the flash 0x60000 onward, which i have read using flash magic, the application refuses to start.
Some of your above statements must be wrong.
If your boot loader programmers exactly the same information at exactly the same locations as FlashMagic, then the end result should be the same.
However, you claim that when FlashMagic performs the programming, the unit boots. When your boot loader does the programming, the unit doesn't boot.
So you must then figure out what your boot loader does wrong when programming the unit.
Your boot loader should complain if it receives data that doesn't end with the 0x01 record. All Intel-hex files should end with such a record. An eprom programmer that gets more lines after the 0x01 record will normally ignore them but should really protest.
The 0x05 record contans the address where the downloaded application wants to start. Your downloaded application should either be written to start from the start of the target address (0x60000) or your boot loader must remember the value from the 0x05 record and jump to that address.
where is the data represented to by record type "05" stored on the chip??
That obviously depends on you.
Most chips with factory-installed boot loader just requires that the application must start at a fixed address, so the value in the 0x05 record doesn't matter.
If _you_ decide that you want to be able to have individual start addresses for downloaded applications, then _you_ must figure out a good location for storing the value from the 0x05 record.
My recommendation is to force a start address and ignore the 0x05 record. An eprom programmer will always ignore a 0x05 record, for the simple reason that it doesn't have any place to store the value.
I tried it again, the application that is re-programmed with flash magic[that was read from the chip] works while the one flashed by bootloader dsnt
So then dump the chip contents when the boot loader has programmed the chip and when flashmagic has programmed the chip.
Compare and then modify your boot loader until it is correct.
If your two dumps looks identical, then you must be forgetting to dump some region that does differ - maybe your boot loader is either forgetting to program one memory range, or is accidentally erasing some other memory sector.
Maybe the bootloader programs the flash correctly, but then leaves some inappropriate configuration(s) in some register(s)...
Is there some technical difference when a hex code is programmed using ULINK2 or Flashmagic ???
Depends on chip, but normally yes.
ULINK2 is a JTAG interface. The normal way for programming chips with ULINK2 is to copy the data into RAM and download a small code block into RAM. Then call that code block and have it perform the programming. Potentially by calling IAP routines available in the chip or potentially by directly accessing the flash.
FlashMagic normally sends the data to a bootloader already available in the chip, and that boot loader erases and programs flash sectors.
Both alternatives results in "random noise" at different areas of the RAM, that may affect a program that doesn't correctly initialize all variables.
FlashMagic normally transmits the speed of any connected crystal, to allow the boot loader to use this crystal for controlling the serial port and any timing for the flash programming.
It's hard to say what hardware the ULINK2 may potentially touch.