• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 1388 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Copy Flash API from ROM to RAM

Dirk Harms
Prodigy 100 points

Is it posible to copy the Flash API from the C28023 Boot ROM to RAM and execute it there ?

The Flash API Samples either user the API from ROM directly or link the API Library and copy the Library from Flash.

If I use the Linker File Definitions from teh Example together with the ROM API Symbol Library the Symbols Flash28_API_LoadStart, Flash28_API_LoadEnd and Flash28_API_RunStart all Point 0x8000 (RAM).

Propably this is because the Library only defines the Symbol Addresses but doesn't fit anything to memory.

Assuming I ignore this Problem and copy the complete Rom into L0 Ram, calculate the correct Addresses and execute any of the Funtion. Will the call Sub-Functions relative and run completely from RAM or do the call their SubFunctions by fixed Addresses in ROM ?

Background:

I try to prevent a lock of the device if it is interrupted during the erase of the password sector. The idee is to have a bootloader in spi flash check if there is a password set and call a clear function programmed into OTP. As far as i understand the code security module, for this to work the Flash API must run from secure memory to allow erase of the secured flash. As ROM is not secure memory the function in OTP would have to copy the Flash API into the secure L0 memory and run it from there.

  • 0
    TI__Guru* 90955 points

    Dirk,

    Unfortunately the ROMed API can't be copied to RAM for execution. Please see this post: http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/170158#pi316717=3&pi316717filter=answers&pi316717scroll=false

    Regards
    Lori

  • 0 in reply to Lori Heustess
    Prodigy 100 points
    Thanks for the answer.

    Linking the Flash API to my loader dosen't work as it is to big to be fit into the unsecure memory (M0/M1/OTP).
    As I understand your reply in the other thread, the source code of the library is not available so I cant just link the functions necessary for clearing the flash ?
  • 0 in reply to Dirk Harms
    TI__Guru* 90955 points

    Dirk Harms said:
    Linking the Flash API to my loader dosen't work as it is to big to be fit into the unsecure memory (M0/M1/OTP).

    Dirk,

    If you would like to run the flash API from unsecure memory, then you can use the API that is in the ROM of the device.  Running from unsecure memory (RAM or ROM) will require that the flash also be unlocked.

    Dirk Harms said:
    As I understand your reply in the other thread, the source code of the library is not available so I cant just link the functions necessary for clearing the flash

    The linker will only pull in the parts of the library that are being used by your application.  For example if you are only using "program" then only those functions will be pulled in.  If you are doing an "erase" then parts of program and compaction will also be included since erase requires a pre-clear of all bits and a post compaction step.

    Regards

    Lori

  • 0 in reply to Lori Heustess
    Prodigy 100 points

    What I like to do is having a bootloader in SPI which is starts in unsecure memory and can jump to an erase in secure memory (otp). if a password is set. This should be used to clear a password set through an unfinished erase operation. 

    Using the Flash API dosen't work as it is in unsecure memory and can't be copyed to secure memory.

    Unloking dosen't work either as the password might be zero and can't be matched.

    This means the Flash API which is needed for erease has to fit eighter in the unsecure ram memory loaded from spi and copyed to secure ram from an otp function, or it must be placed into the otp. 

    But currently it seams that the api is to big for any of this options as it links 1150Bytes from the Flash API if i use the erase Function.

    I have one last Idee but i think its better to open a new thread for this.

  • 0 in reply to Dirk Harms
    TI__Guru 55700 points

    Dirk Harms said:

    What I like to do is having a bootloader in SPI which is starts in unsecure memory and can jump to an erase in secure memory (otp). if a password is set. This should be used to clear a password set through an unfinished erase operation. 

    Using the Flash API dosen't work as it is in unsecure memory and can't be copyed to secure memory.

    Unloking dosen't work either as the password might be zero and can't be matched.

    Yes, you can't work on secure memory from unsecure memory unless you unlock the device. So, this option might not be available.

    This means the Flash API which is needed for erease has to fit eighter in the unsecure ram memory loaded from spi and copyed to secure ram from an otp function, or it must be placed into the otp. 

    But currently it seams that the api is to big for any of this options as it links 1150Bytes from the Flash API if i use the erase Function.

    Can customer try embedding a customer code (with flash api) with flash erase function to recover the device in case of accidental locking of device? You can use GPIO status to decide the whether to erase the flash.