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.

CC2640: Code Protection without bricking

Part Number: CC2640

I'm nervous about experiment with Code Protection.

Can someone confirm for me 1, 2, and 3?  (before I accidentally brick my prototype):

To protect my code BUT STILL be able to reprogram my chip, I set the Flash Access Config Registers as:

1.) To prevent reading code:  Disable Bootloader, Disable JTAG (TAP/DAP), Disable TI FA

2.) To prevent CCFG sector overwrite: Disable Bank Erase

3.) To allow me to reprogram then debug with CCS (or Flash Program App ): Enable Chip Erase

PS: Separately, where do I set these CCFG values in the BLE example CCS projects? (I remember seeing this somewhere but I can't find.)

Thank you.

  • Hi Dan,

    As long as you do not set ERASE_CONF:CHIP_ERASE_DIS_N to "0" you will be able to do a mass erase and thus get the chip back to a fully open state.

    1) Correct.
    2) Flash page erase/write protection is done through the CCFG_PROT_n registers.
    3) Yes (this is enabled by default).

    CCFG configuration is done in ccfg_app_ble.c (found in the Startup folder in the project files). Read the information in the file on how to make changes.

    Cheers,
    Fredrik
  • Fredrik,

    Thanks for the help. I have some follow questions on (2). Can you address a, b, and c?

    a.) To use the CCFG_PROT_n register, how would I determine which sector the CCFG registers are in?

    b.) Would disabling Bank Erase work to protect the CCFG registers from attack?

    c.) Do I even have to worry about this? Is there a way for and attacker to erase the CCFG registers and thereby gain access to my code?

    Thanks again,

    Dan

  • Hi Dan,

    a) CCFG is always located on the last flash page.

    b) Bank Erase is basically a full erase performed by the ROM bootloader. Bane Erase will not erase pages write protected by CCFG_PROT_n.

    c) To protect readout of the flash content of your device you should lock the JTAG interface and lock the ROM bootloader interface. Additionally you should write protect as much of the flash as possible to protect against unintentional erases and writes. You may consider disabling mass erase through JTAG also. Just keep in mind that it will also prevent your self from erasing and accessing the chip.

    See the "Device Configuration" chapter in www.ti.com/lit/pdf/swcu117 for details.

    Cheers,
    Fredrik
  • Fredrik,

    Just to be clear, I'm not worried about MY code erasing CCFG. I just want to secure CCFG agains outside attack.

    I don't want any security holes (i.e., code read or CCFG hack), but I still want to use "osal_snv_write". So I need to be careful using CCFG_PROT_n. Right?

    Separately, (to confirm) Which erase does CCS do when I connect and program?

    thanks,
    Dan
  • Hi Dan,

    I would highly recommend locking the CCFG flash page and not updating this after production. The pages used by SNV must be left open, but any pages containing code that not will be updated or change later should be protected.

    CCS does a bank erase before programming I believe. Flash Programmer 2 can run all three types of erases (page-, bank- and mass erase). A page erase erases single pages, bank erase erases all pages that are not protected and bank mass erase erases the entire flash regardless of protection. 

    To protect your binary image from readout you must lock the JTAG and the ROM bootloader. This will still allow mass erase through JTAG (NOT page- and bank erase), but you can block that as well through a dedicated CCFG entry. 

    Cheers,
    Fredrik

  • Oh. Cool. So I'm completely secured against attack if I just lock the JTAG and ROM bootloader? No known way to steal my code? (I can forget about page/bank erase and the CCFG_PROT_n registers?)
  • Hi Dan,

    That is correct!

    Again, I would still recommend you to lock as much of the flash as possible :-)

    Cheers,
    Fredrik
  • Fredrik,

    You've cleared up every one of my code security concerns.

    It's still not clear to me why to set those lock bits (I've never seen accidental flash writes. TI RTOS issues, perhaps?), but that is a post for another day.

    Great replies! Thank you.

    -Dan