• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 83 subscribers
  • Views 1124 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.

CCS/TMS320F28377D: Flash memory fails in secure mode

Jouko Viitanen
Intellectual 280 points
Part Number: TMS320F28377D
Other Parts Discussed in Thread: CONTROLSUITE

Tool/software: Code Composer Studio

Dear Expert,

I am debugging F28377D within CCS6.1.1 environment. I have code to program 8 words to the flash memory of CPU2. I use the flash API example program from the Controlsuite device_support, v200 ( but downloaded the latest F021 library). Writing to the flash goes ok when debugging in the nonsecure mode. However, when I program the CSM and lock the device, programming fails. Other code runs ok when secure.

The flash programming routine runs in the secure RAM zone D1, and the sector to be written is L, i.e. starting from 0xBA000. The whole flash is also set secure, i.e. I have codes 0x15555555 in the Z1_GRABSECT, and 0xD0005555 in the Z1_GRABRAM. I have the default Z1 zone, i.e. linkpointer all F's.

The flash programming instructions say that if both the programming code and the flash are secure, writing should not need unlocking. However, I also tried with a version where I run the unlocking routine before calling the F021 routines, but the result was still unsuccessful.

For some reason, I also needed two subsequent flash erase F021 calls before successful writing in the nonsecure mode. These are also included in the secure version. I guess the optimization levels do not have any importance here, because everything is done in the library functions? (I have -O 1 and speed vs. size at 5), the clock frequency is 180MHz.

I could not find any mention about the flash ECC memory range secure/nonsecure settings, so I guess it is irrelevant? I just noticed that if I use the flash write example that does not include the ECC for CPU2, then CPU1 receives a boot error from CPU2, therefore I need to use the ECC write version.

Any ideas what goes wrong? Debugging is quite difficult when the secure lock is set, so I would need an expert opinion!

Best regards,

Jouko

  • 0
    TI__Guru* 87105 points
    Jouko,

    In order to avoid conflict between zone1 and zone2, a semaphore (FLSEM) is provided in the DCSM registers to configure Flash registers (please check TRM for more details on this register). The user application should configure this semaphore register before initializing the Flash and calling the Flash API functions. Please check whether you configured this or not. I will ask our security expert to take a look at this post.

    Also, see this wiki: processors.wiki.ti.com/.../C2000_Flash_FAQ
    Please search for "What are the common debug tips that we can consider when Flash API fails to erase or program?" in the wiki. It mentions that FLSEM configuration should be checked.

    Thanks and regards,
    Vamsi
  • 0 in reply to Vamsi Gudivada
    Intellectual 280 points
    Thanks Vamshi of the very rapid reply,

    I have only activated zone1 (i.e. all z2 settings are 0xFFFFFFFF) so I wonder if any conflicts can happen?
    I have another board where the security codes have not been activated, and checked there that the FLSEM is 0, and it has not been changed (it also seems to be the reset default).
    Could not yet check the situation in the secured board due to the difficulties in debugging (I probably need to add an
    extra switch to the board to allow easier change of the boot wait/boot from flash –modes, so that I can either unlock
    the device or run it secure), but because the FLSEM is not changed in my code, it probably stays at 0?

    I try to check the other FAQs, too.

    Best,
    Jouko
  • 0 in reply to Jouko Viitanen
    TI__Guru** 113745 points

    Juko,

    You need to set FLSEM value to '1' to enable flash programming operation for Zone1.

    Please make this change and it should fix the issue.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Intellectual 280 points
    Thanks Vivek,

    First a question about the manual version, because I have a version spruhm8e.pdf (sept 2015), and it has a slightly different description of the FLSEM fields, i.e. when SEM=00 "...registers can be written by code running from anywhere without any restriction".
    I am asking this because this addition does not seem to make any difference (I still need to verify it - this observation is based on the behavior of my code, but I need to solder the switch to easier go between the boot modes, and be able to go to the debugger to check it for sure). Perhaps the new manual has other changes, too.

    I also added the ECC disable instruction from the sample code, but since my chip version is a newer one,
    it was not relevant, as expected.

    The FLSEM also has the KEY field. I wrote it first, and then the SEM field. Perhaps they need to be written in the same cycle??

    Best,
    Jouko
  • 0 in reply to Jouko Viitanen
    TI__Guru** 113745 points

    Hi Jouko,

    First a question about the manual version, because I have a version spruhm8e.pdf (sept 2015), and it has a slightly different description of the FLSEM fields, i.e. when SEM=00 "...registers can be written by code running from anywhere without any restriction".

    You are right. We have modified the description in new document because it was a bit confusing hence some users were not grabbing the semaphore for secure flash operations (like you mentioned).

    The FLSEM also has the KEY field. I wrote it first, and then the SEM field. Perhaps they need to be written in the same cycle??

    That is correct. KEY and the semaphore value need to be written together (e.g. 0xA501).

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Intellectual 280 points
    Thanks Vivek and Vamsi, that solved the problem. I should have loaded the new manual with clearer text. Double confusion came from the sample program that has a command for flash pump seizing, but it only switches it between the cores, but not between the zones!

    Regards,
    Jouko
  • 0 in reply to Jouko Viitanen
    TI__Guru** 113745 points

    Hi Jouko,

    No problem. Glad to know issue is resolved. Flash pump semaphore is different than this one. I assume sample program you are referring is not securing the device hence it does not switch the flash semaphore.

    Regards,

    Vivek Singh