• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 86 subscribers
  • Views 177 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.

TMS320F28P559SJ-Q1: Flash Bank and Index Library Linking Issues in F28P559SJ9 with algorithm project and testing project flashing separately

Cesc Yang
Prodigy 131 points
Part Number: TMS320F28P559SJ-Q1

Tool/software:

I am working on the F28P559SJ9 board, using DCSM (Dual Code Security Module) to lock Flash bank4 where the crypto algorithm library is stored. My goal is to compile an index library and integrate it into a separate test project that calls the algorithm interfaces to verify the functionality.

The issues only occur when separating the algorithm and test projects into two different projects and linking them through the index library. When tested within a single project, the algorithm works without any issues.

Specific issues:

  1. Global variables issue:

    • I used #pragma DATA_SECTION to place global variables (less than 1KB) into Flashbank4. However, when debugging, I found that the memory addresses are filled with 0xFF and cannot be modified, preventing the algorithm from functioning correctly.
    • When I moved the global variables to local variables, a stack overflow occurred. I then allocated memory dynamically using malloc, which worked fine in the single project setup. However, when burning the library to Flashbank4, compiling the index library, and linking it to the test project, calling the algorithm caused an error interrupt, which seems like an invalid memory access.

  2. Memory configuration and interrupt issue:

    • The .stack and .sysmem sections in both the algorithm project and the test project are configured identically:
      • .stack : > RAMGS0
      • .sysmem : > RAMLS4
    • The available space in RAMGS0 and RAMLS4 should be sufficient, but in the test project, calling the algorithm through the index library results in an error interrupt.

My questions:

  1. Why does placing global variables in Flashbank4 using #pragma DATA_SECTION result in them being filled with 0xFF and unmodifiable?
  2. Why does calling the algorithm cause an error interrupt when the algorithm and test projects are separated into two projects, despite using the same stack/heap configuration and sufficient memory available in RAMGS0 and RAMLS4?
  • +1
    Prodigy 60 points

    Just a hint for question number 1:

    You want to have sercure data stored in Flashbank4, and in the same time to have modifiable data stored in RAM somewhere for the algorithm; since data stored in flash must have the const identifier (and of course you cannot change it as you do with normal variables because it is stored in flash), maybe it can be an idea to store in Flashbank4 a constant initialized variable with data, and then load data in a RAM variable (and you could place it in secure RAM also) that your algorithm will use...

  • 0 in reply to agostino facotti
    Prodigy 131 points

    Hi agostino.


    Thank you for the suggestion. I will try not storing the variable in Flash within the algorithm project and instead place it directly in RAM using #pragma DATA_SECTION in secure RAM. Does this approach work?

    Additionally, would the test project need any special configuration to avoid operating on secure RAM, or could it remain unchanged?

    Best Regards,

    Cesc

  • 0 in reply to Cesc Yang
    TI__Mastermind 19520 points

    Hello Cesc,

    Just wanted to let you know the TI expert is currently out of office until 10/21, so please expect a delay in response before then. Thank you for your patience.

    Best Regards,

    Allison

  • +1 in reply to Cesc Yang
    Prodigy 60 points

    Hi Cesc, 

    Yes, it should work; just pay attention to the fact that initialization data will be placed in .cinit section of linker command file, which can be on an unsecure memory (but you can then declare a constant variable that holds data and place it where you want as said before); my suggestion is to proceed step-by-step and check which approach is the best 

    Best,

    a.