• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Subscribers 84 subscribers
  • Views 1365 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.

TMS320F28377D: Flash API F021 fails in secure mode

Schmidhauser AG Schmidhauser AG
Prodigy 90 points
Part Number: TMS320F28377D

Hi Vamsi and Vivek

 

I tried to modify the flash programming example CPU1 for the F28377D to run with secured flash and RAM.

 

I started from the Control Suite V170 example (\F2837xD\v170\F2837xD_examples_Dual\flash_programming\cpu01). I added

 

DcsmCommonRegs.FLSEM.all = 0xA501;

 

at the very beginning of InitFlash() to grab the flash semaphore as it was recommended in (https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/660432?tisearch=e2e-sitesearch&keymatch=Flash%20API%20F021%20CSM and https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/642405?tisearch=e2e-sitesearch&keymatch=Flash%20API%20F021%20CSM).

 

Additionally I uncommented the flash erasing part at the end of the example to be able to check if the flash operation was successful. The example writes test data at the beginning of the flash sector B (0x82000) and C (0x84000).

 

My security settings are the following:

 

Z1-GRABSECT on 0x35555555 (whole flash bank 0)

Z1-GRABRAM on 0x30005555 (LS0-LS5, D0-D1)

Z1-CSMPSWD0-3 on 0xxxxxxxx

 

After securing (and let the example code run at least once) I unsecured the device and checked the flash sectors for the test data. If the device was secured the flash is on 0xFFFF. If the device is not secured the test data (0x0001, 0x0002 ..) stays in the flash.

 

Is there anything else I forgot to change so that this example runs in secured mode?

Could you provide an example which works in secured mode?

 

Best Regards, Benjamin

  • 0
    TI__Mastermind 32995 points

    Hi Benjamin,

    Can you explain more of what you are seeing? How do you know they example is not running from secure memory?

    You need to ensure that the data you are trying to program is either in the same zone or unsecure memory, and the flash API is in the same zone you are trying to erase and program. If this is so, then the code should be able to erase and program the secure flash.

    Regards,
    sal

  • 0 in reply to Sal Pezzino
    Prodigy 90 points

    Hi Sal

     

    I see that the flash is still on 0xFFFF instead on the test data (0x0001, 0x0002 ..) after unsecuring the device again. For that I uncommented the flash erasing part at the end of the example code.

     

    My test procedure in detail:

    1. setting boot mode to "Wait Boot Mode"

    1. flashing of the example project
    1. securing the device
    1. boot mode to "Get Mode"
    1. power cycle the board 1-2 to be sure that the example code runs through
    2. boot mode to "Wait Boot Mode"
    3. unsecuring the device
    1. checking the flash via Memory Browser

     

    If I skip step 3 and 7 (no securing and unsecuring of the device) the test data stays in the flash, else not.

     

    As I understand the linker file of the example project the flash API is running in secured RAM (LS0-LS3) so the flashing of the secure flash should work.

     

    Did I forget something else?

     

    Thanks for your support, Benjamin

  • 0 in reply to Schmidhauser AG Schmidhauser AG
    TI__Mastermind 32995 points
    Hi Benjamin,

    I don't think you forgot anything. As long as the flash API and the code calling the flash API is in the same zone in RAM as which you are trying to program, then it should work. Can you confirm the flash API is also linked to secure RAM?

    Also, where is the data you are trying to program? As long as it is in the same zone or unsecure, then it should work.

    Regards,
    sal
  • 0 in reply to Sal Pezzino
    Prodigy 90 points

    Hi Sal

    I changed nothing at the example regarding the mapping. So far I understood the code everything is running in secured RAM.

    The data the example code tries to program is at the beginning of the flash sector B (0x82000) and C (0x84000) which are secured via the Z1-GRABSECT setting.

    Regards, Benjamin

  • 0 in reply to Schmidhauser AG Schmidhauser AG
    TI__Mastermind 32995 points
    Benjamin,

    If you are trying to erase and program Sectors B and C, and that is the same place you are storing the data, then the data will be lost when you preform an erase (0xFFFFFFFF). The data cannot be stored in the location you are updating.

    I hope I have understood you correctly.

    Regards,
    sal
  • 0 in reply to Sal Pezzino
    Prodigy 90 points

    Hi Sal,

    No, you didn't understood me correctly!:)

    I modified the example so that the data remains in sectors B and C. The example works if the device is not secured.

    Shall I send you the example code?

    BR Benjamin

  • 0 in reply to Schmidhauser AG Schmidhauser AG
    TI__Guru** 113745 points
    Hi Benjamin,

    Are you grabbing the Flash semaphore to update the secure flash sectors. Please refer the post below on this -

    e2e.ti.com/.../2426101

    Regards,

    Vivek Singh
  • 0 in reply to Vivek Singh
    Prodigy 90 points

    Hi Vivek

     

    Yes, I grab the Flash semaphore. Please see my first post.

     

    Regards, Benjamin

  • 0 in reply to Schmidhauser AG Schmidhauser AG
    TI__Mastermind 32995 points
    Hi Benjamin,

    It is not clear to us what the issue is right now, if in fact you are doing what you have described.

    Can you please attach a small example which demonstrates this behavior?

    Regards,
    sal
  • 0 in reply to Schmidhauser AG Schmidhauser AG
    TI__Guru** 113745 points
    Benjamin,

    Can you add a simple toggle at the end of your code to see if code is executing till end when device is secure? Other method is to run the device with CCS connected but ECSL unlock and debug it. Follow below-step.

    * Set the Wait BOOT
    * power-up the device
    * Connect the CCS
    * Issue debug reset
    * Load symbol for your project
    * unlock ECSL (not CSM) using Flash plug-in GUI (this is done by providing 64bit LSB password).
    * Write 0x035A at address 0xD00 from CCS memory watch window.
    * set the hardware breakpoint at your main entry point.
    * Click the run button. If CPU halts at at ESTOP then click on RUN button again.
    CPU should at your main entry point (hit the breakpoint). Now you should be able to step through the code and see if execution is happening as expected. You'll not be able to see any CPU register content because device is still secure but you should step thorough the code.If there is any problem then you will see execution crashing.

    Let us know how it goes.

    Regards,

    Vivek Singh
  • 0 in reply to Schmidhauser AG Schmidhauser AG
    TI__Guru* 87105 points
    Hi Benjamin,

    One more thing to check: Can you try using the example from Control Suite V210 instead of V170? You will notice that the functions in the Fapi_UserDefinedFunctions.c file are assigned to .TI.ramfunc section (to copy to RAM at run time). In your case, please make sure that these functions are also copied to the same zone RAM.

    Thanks and regards,
    Vamsi
  • 0 in reply to Vivek Singh
    Prodigy 90 points

    Hi Sal and Vivek

    I added a debug pin toggle at everey step into the code example. To make the example running more than once I activated the erasing of the sectors B and C at the end of the example again. The debug pin shows me that the code is running through until the end in both secured and unsecured mode. Please see the attached figure (be aware that the time resolutions are not the same for secured and unsecured mode!).

    In the secured mode the erasing steps are faster than in unsecured mode. I think thats because the data of the whole flash bank is still on 0xFFFF in secured mode.

    Have you any ideas why it is different?

    Regards, Benjamin

  • 0 in reply to Schmidhauser AG Schmidhauser AG
    TI__Guru** 113745 points
    Benjamin,

    Not only erasing but even programming step is much faster in secure mode which means API is existing without actual program/erase operation. It can happened due to two reason.
    1) API is not running from secure memory.
    2) Flash semaphore is not written correctly (you can read back this in your code and check if the value is 0x1 (read value for KEY will be 0x0).

    Were you able to step through the code in secure mode by following the steps, I mentioned ?

    Regards,
    Vivek Singh
  • 0 in reply to Schmidhauser AG Schmidhauser AG
    TI__Guru* 87105 points

    Benjamin,

    As suggested yesterday, can you confirm that the functions in the Fapi_UserDefinedFunctions.c file are assigned to .TI.ramfunc section (to copy to RAM at run time)? RAM should be of the same zone as that of the Flash sectors on which erase/program is targeted.

    Thanks and regards,
    Vamsi

    Flash API wiki: http://processors.wiki.ti.com/index.php/C2000_Flash_FAQ#Flash_API_wiki

  • 0 in reply to Vamsi Gudivada
    Prodigy 90 points

    Hi Vamsi and Vivek

    I'm sorry Vamsi, I haven't noticed your comment. I tested it again with following changes:

    - copy API user functions to secure RAM
    - read back of SEM field to check if it is on 0x1

    The result is that the SEM field was still on 0.

    However, although referring the documentation (spruhm8g) that is not needed I disabled the write protection (EALLOW) and that solved the problem!



    So many thanks for your support and please correct this in the documentation and add this grabbing of the flash semaphore into the future releases of the flash example!

    Best regards, Benjamin