This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

In Application Programming for LPC2368

Dear All;

I am working for an automotive project using LPC2368. Here, I want to write datas from CAN network to the 512KB Flash of LPC2368 while application is running . The data, we want to store is some critical data from CAN network.As per IAP standard we have to reduce the CPU clock while Programming the FLASH. If we are reducing the clock while CAN is working ,this is affecting CAN reception.As a solution ,if we getting the data from the CAN network ,first we are writing these data to 2KB of Battery RAM and then writing from battery RAM to FLASH while bigining of next booting time.Here for every booting time ,first of all read data from FLASH and attach data from battery RAM and then write whole data again to same FLASH.Now Flash contain a sequence of DATA from battery RAM . This methode is working fine for ISP programming.But if I am using JTAG ,all the previous data get erased
from Flash.hence I will be having only last data from Battery RAM. Will you please tell me that ,what is the difference in downloading the hex file using JTAG and ISP .How old data from flash get erased , when we ae using JTAG.

sincerely shamsudheen OP

Parents
  • When upgrading the application using the JTAG interface, you most definitely want to erase flash sectors. Just not all sectors.

    Have you tried my two suggestions?

    By the way, resetting the chip should not affect the retention of the flash sectors. Are you sure that it isn't your own IAP code that destroys your data sectors if you reset the chip several times quickly? For example because your IAP code is busy to save data from the battery-backed RAM when you reset the controller a second time?

Reply
  • When upgrading the application using the JTAG interface, you most definitely want to erase flash sectors. Just not all sectors.

    Have you tried my two suggestions?

    By the way, resetting the chip should not affect the retention of the flash sectors. Are you sure that it isn't your own IAP code that destroys your data sectors if you reset the chip several times quickly? For example because your IAP code is busy to save data from the battery-backed RAM when you reset the controller a second time?

Children
  • dear sir;

    sorry for mentioning that ,me allready checked the two suggestion.
    1>In the setting ,it is in "Erase Sectors" . this will not make any problem,because ,some data allready there in some sector of FLASH,which is not erased even after downloading.

    2>I used sectors of sizes 4K (0x7B000),32k (0x58000)still the problem exists.

    "Are you sure that it isn't your own IAP code that destroys your data "

    this I do no,Will u please tell me,how to monitor the same.

  • "2>I used sectors of sizes 4K (0x7B000),32k (0x58000)still the problem exists."

    I'm not sure I follow your logic. I wasn't asking for how much of the flash you use for your data storage. I wondered if you have tried to change the project settings, and specifying a smaller flash. The LPC2368 has 512kB flash. What happens if you say that your chip only has 256kB flash - i.e. the same amount as the LPC2366?

    Whenever your application boots, you have written that you copy data from the battery-backed RAM to flash. During that copy procedure (until the IAP is ongoing) you must not reset the chip, or you will not know in what state the IAP is. If this works or not depends on how the programming algorithm requests erase of the chip. If the request is to erase everything, then it doesn't matter what size the project says the flash is. If the request is to erase a memory range, then decreasing the flash size in the project will decrease the number of sectors that will be erased.

    Have you tried to write a flag to the battery-backed RAM when you start the IAP and clearing the flag when the IAP is done? If your program boots and finds that this flag is already set, then you know that the previous IAP attempt got interrupted. Then you also know that your code performs the IAP within a time span where it is sensitive to the multiple resets caused by the programming, and all bets are off about the retention of data in your IAP-programmed flash area.