• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 312 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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_Demo

Ahmed Hassan1
Prodigy 105 points
Other Parts Discussed in Thread: TM4C123GH6PGE

Hi,

I am using Tm4c123gh6pge when i trying the eeprom demo emulation example i found that it forces  me whne using the 

SoftEEPROMInit(unsigned long ulStart, unsigned long ulEnd,unsigned long ulSize)

\param ulStart is the start address for the EEPROM region. This address
//! must be aligned on a 4K boundary.
//!
//! \param ulEnd is the end address for the EEPROM region. This address is
//! not inclusive. That is, it is the first address just after the EEPROM 
//! emulation region. It must be aligned on a 4K boundary. It can be the first
//! location after the end of the Flash array if the last Flash page is used
//! for EEPROM emulation.

So i have two questios

1)i don't understand why it forces the UIstart and UIENd to be aligned on 4 kB boundaries ?

2)By using this technique do i need to modify the linker command file to decrease the flash area so as not to overwrite the code when i load my non volatile parameters in that EEPROM emulation section determined by that function?

Thanks 

  • 0
    TI__Guru**** 244400 points

    Hello Ahmed,

    Which example in the TIVAWare are you referring to for the SoftEEPROMInit?

    As for the second part of the post, if the flash is used to emulate an EEPROM, then yes, you would need the linker file to reduce the size of flash so that the code does not enter the region of emulated EEPROM

    Regards

    Amit

  • 0
    Guru 26105 points

    Hi,

    You have cross-posted, and already you have a response here.

    Relating to your question 2) - yes, to be safe from the development point of view. You can initiate the area at run-time also with a default configuration and the user can modify as needed (I use this approach).

    Petrei

  • 0 in reply to Petrei
    Prodigy 105 points

    Peteri,

    Thanks for you reply, could you declare more the approach you have mentioned ?

    Thanks

  • 0 in reply to Ahmed Hassan1
    Guru 26105 points

    Hi,

    OK, my considerations are:

    - I use a "default" configuration - for several reasons: a) avoid two separate programs writes to micro - on production line means spending time; b) accidentally the "data" write may be also avoided so your program will use un-initialized data, giving unexpected behavior (my program/module cannot run without real data, 0xFFFF is excluded); c) why not to do it automatically?

    - The initialization routine is very clever - determines if some sector is in use and just read the working parameters, so no erase/write-again-defaults occur; you are safe to use the new, user modified data.

    - Really I did not modified the linker margin - I use the program as it is (my responsibility) and erase all at the first flash write on production line, then, if needed, to erase only the sectors occupied by the program (automatically done by LMFlash) but this is only one time in 1000 pcs delivered...

    Petrei