This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EEPROM emulation on F28015

Other Parts Discussed in Thread: SPRC327

Hi , Im confused i want to save some data in EEPROM (program memory) and I have installed required files API (SPRC327, SPRAB69) and did the changes to the code but my debugger cannot step after calling flash_erase(...) or flash_write(...) functions which you can find in F280xx_EEPROM.c file. Debugger says it cannot find the source of those functions and I couldt find them either manually. Could anyone please tell me where are those function files? (I have installed all above libs as well). Thanks in advance.

Rupert.

  • Hi Rupert,

    As i know, its a library call to Erase and Write the data in to the Flash. Hence you will not be able to step in to the source code.

    As you have mentioned its an API call, and you will be using the compiled library.

     

    If you do not have any constrain on the timing of operation, then you can use the EEPROM emulation, else it will have severe impact on your program execution timing,.

     

    Regards,

    Mohan

     

     

  • Thanks Mohan,

    Yes you are right. Now my issue is when I run the Ti EEPROM emulation example code for F28015, it always returns 0xFFFF in Read_Buffer. The code writes some values and then reads, but at the end of the code (stopped the debugger) the read buffer values are0xFFFF. It seems to be the code desnt write to the flash. But this is not my code its Ti's example code, and it compiles without errors and i have all libraries installed. ? Any idea why its doing this?

    Regards

    Rupert.

  • Hi,

    Sorry for the delay.

    If you are reading 0xFFFF means the flash has been erased. The erased state of FLASH contains all one's.

    you have the option to write your own data, by writing the same in to the write buffer. The TI sample code write 0xABCD in all 64 locations.

    Hence you should be able to read 0XABCD.

    You can change the code for 64 bytest oto 1 byte and check, why.. and try to step in using single step debugging for the wrtie section of the code.

    Check you data till you reach the API fucntion call for write. You may get some points.