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

Problem updating flash program memory

I would appreciate any help getting past this problem.

I am attempting to write code that I can use to update the program in flash memory.

I am using the xc16x_iap-flash example and so far have successfully managed to locate the flash programming section to RAM and am able to erase and write to flash memory from it.

The next part has me confused though. When I erase the sector 0xC00000 (beginning of flash memory) the program in RAM stops running. It appears as though constants from my program in RAM are being stored in flash.

I assume that I am missing something in the L166 Locate Options, but after trying many combinations I am quite lost on how to set this up correctly.

Keil xc16x_iap-flash example:
http://www.keil.com/download/docs/xc16x_iap-flash.zip.asp

Parents
  • Perhaps I don't understand your question but are you running the example as is only changing the define value of FLASH_ADR to be 0xC00000? This will not work unless you also move all the code in the main to a function in the PRAM (except hmemcpy).

    Not sure why you want to do this but the reason for your failure is that the Srom.C code is located in the first sector i.e. 0xC00000. So when you erase the sector by a function call from the flash sector to the PRAM. This flash erase command is executed and then returns to the flash only to find that the code is gone…

    Make the other necessary changes to your code and try something like this.

    Code in Srom.c

    void main (void)  {
      // copy flash program code to execution address
      hmemcpy (SROM_PS_TRG(PFLASH), SROM_PS_SRC(PFLASH), SROM_PS_LEN(PFLASH));
    
      mainRAM();
    }
    

    Code in pflash.c
    unsigned long const base = 0xC00000l;            // Device Base Address
    
    void mainRAM (void)  {
    
      _bfld_ (PSW, 0xF000, 0xF000); // disable interrupts
      PFlash_Erase (FLASH_ADR);        // Erase sector starting at address 0x4000;
      _bfld_ (PSW, 0xF000, 0x0000); // enable interrupts
    
      _bfld_ (PSW, 0xF000, 0xF000); // disable interrupts
      PFlash_Write (FLASH_ADR, buf);   // program 64 bytes to address 0x4000;
      _bfld_ (PSW, 0xF000, 0x0000); // enable interrupts
    
      while (1);
    }
    

    Of course if this doesn't answer your question then would it be possible for you to rephrase it for a better response?

    Best regards,
    -Chris

Reply
  • Perhaps I don't understand your question but are you running the example as is only changing the define value of FLASH_ADR to be 0xC00000? This will not work unless you also move all the code in the main to a function in the PRAM (except hmemcpy).

    Not sure why you want to do this but the reason for your failure is that the Srom.C code is located in the first sector i.e. 0xC00000. So when you erase the sector by a function call from the flash sector to the PRAM. This flash erase command is executed and then returns to the flash only to find that the code is gone…

    Make the other necessary changes to your code and try something like this.

    Code in Srom.c

    void main (void)  {
      // copy flash program code to execution address
      hmemcpy (SROM_PS_TRG(PFLASH), SROM_PS_SRC(PFLASH), SROM_PS_LEN(PFLASH));
    
      mainRAM();
    }
    

    Code in pflash.c
    unsigned long const base = 0xC00000l;            // Device Base Address
    
    void mainRAM (void)  {
    
      _bfld_ (PSW, 0xF000, 0xF000); // disable interrupts
      PFlash_Erase (FLASH_ADR);        // Erase sector starting at address 0x4000;
      _bfld_ (PSW, 0xF000, 0x0000); // enable interrupts
    
      _bfld_ (PSW, 0xF000, 0xF000); // disable interrupts
      PFlash_Write (FLASH_ADR, buf);   // program 64 bytes to address 0x4000;
      _bfld_ (PSW, 0xF000, 0x0000); // enable interrupts
    
      while (1);
    }
    

    Of course if this doesn't answer your question then would it be possible for you to rephrase it for a better response?

    Best regards,
    -Chris

Children
No data