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.

CC1310: Looking for suitable CCFG settings for production

Part Number: CC1310

Hey guys,

this is a related question to this post. I am looking for suitable CCFG settings to avoid the readout of the flash content in order to protect IP. We have a TIDA 00489 board which is flashed via JTAG and a collector board which is flashed via USB and an XDS110 probe similar to the CC1352R1 launchpad.

What I want:

  1. The content of the flash should be protected. Hence, no one can simply readout the flash.
  2. I still want to be able to re-flash the sensor board via JTAG
  3. The collector should still be updateable via the USB connection
  4. Optional: The sensor should be upgradeable via ODA

As discussed in the related post, point 4 should work since an SPI connected external flash would be necessary for off-chip OAD with the cc1310. Regarding point 3, we currently use the Serial Bootloader Application from the Linux 15.4 SDK and would like to keep the opportunity to update the collector board. Point 2 is necessary, since we dont want to brick our board, if something goes wrong during the flash process. We have a test identifying an invalid flash process during production and simply flashing it again usually solves it.

Regarding the CC1310 (Sensor settings):

I have re-read the section 9.1 of the technical reference of the CC13x0 manual but I am still not quite sure if I understand it correct. Is it simply enough to disable SET_CCFG_BL_CONFIG_BOOTLOADER_ENABLE and  SET_CCFG_BL_CONFIG_BL_ENABLE?

Regarding the other points (2-7) in the technical reference, I assume I can leave them at their default values, since they do not grant access to the flash content?

Regarding the CC1352R1 (Collector settings):

Here it seems to be more difficult, since the bootloader and its backdoor cannot be disabled. Is there a work around to allow serial bootloader flashing but somehow disable access afterwards? Something like a password necessary to allow acces?

Again, I assume the other points are rather not interesting for us if we simply want to protect IP.

Best wishes

Slev1n

  • Hi Slev1n, 

    If you are programming over JTAG, the only solution to not be able to read the chip is to lock the DAP. That also means that you cannot re-program the device without performing a mass erase on the device which will cause the device to forget the previous connections and start from scratch every time you want to re-flash another version. 

    With the serial bootloader, you have to disable it to stop anyone from reading the flash. You can read more about it in the TRM. 

    Can you share some more details about the use-case and requirements for your system?

    Thanks, 
    Elin 

  • Hi Elin,

    thank you for your reply.

    The sensor is used outdoor and to prevent it from humidity damage we have completely encapsulated the board. Hence after flashing it via JTAG during production reprogramming is only possible via OAD in the future. However, we noticed sometimes, that our self-made flash test detects some issue and the board is re-flashed again. We are using a CLI script based on Flash Programmer 2.

    Are there any drawbacks associated with a mass erase? Maybe we could simply integrate a mass erase command in our CLI script if re-flashing is necessary.

    Regarding the collector using the serial bootloader. Sometimes updating the collector board is comfortable to implement new functions. Besides, we use the USB connection to read/write UART cmds and other content to control the collector and use it for debugging the network. Thus, access to the UART line via USB is mandatory and updating via the serial bootloader would be comfortable. Although a JTAG connection would be also present but no such interface is present on our collector controlling device.

    best wishes

    Slev1n

  • Hi Slev1n, 

    Thanks for sharing. 

    The only drawback with the mass erase is that the sensor "forgets" the network it's been connected to previously because everything in flash is erased. So you are essentially getting a new sensor, and it will not be able to reconnect to a network. But since this seems to be in production, you shouldn't have to worry about it.

    Okay, so you want to lock the device even when you are going through the development phase? Otherwise, I would recommend that you don't lock the device when developing and then lock the DAP once you deploy your product(s). 

    Thanks, 
    Elin 

  • The only drawback with the mass erase is that the sensor "forgets" the network it's been connected to previously because everything in flash is erased.

    Hey Elin,

    the sensors are programmed to "forget" about their former network in different scenarios and they are able to join another network afterwards. Our flash-test also contains a network-join test but the sensors will forget about this test-network anyway. So the mass erase is no problem.

    Okay, so you want to lock the device even when you are going through the development phase?

    Well, a deployed device does usually not represent a flawless device. Meaning, it could be that after half a year after the deployment, the customer has a wish regarding a new function. In order to implement this function we could simply "update" our collector via the internet if we have access to the serial bootloader. Hence, write access to the flash without read access would be interesting, though then, no verification would be possible.

    Looking at your first answer, mass erasing the collector would not be an issue, too. Could the solution for the collector be:

    mass erase --> update software via serial bootloader --> reboot and set up new network. If so, does the Serial Bootloader Application from the Linux 15.4 SDK include a mass erase cmd? I remember it has an erase cmd, but is this equally to mass erase?

    best wishes

    Slev1n

  • Hi Slev1n, 

    Great to hear that a mass erase is a solution that works for both your sensor and collector applications. 

    Good question, I'll look into if the linux gateway has a specific mass erase command or if the erase command can be used, and get back to you as soon as I have an update.

    Thanks, 
    Elin

  • Hi Elin,

    while waiting for your answer regarding the mass erase on the serial bootloader tool I went through the documentation of both chips and the conversation with you and I still have a few questions how to proceed:

    • The bootloader and the bootloader backdoor can be kept enabled, right?
    • There are a lot of registers including DAP. Which ones do I have to disable?

    CC1310: CCFG_TAP_DAP_0:PRCM_TAP_ENABLE | CCFG_TAP_DAP_0:TEST_TAP_ENABLE | CCFG_TAP_DAP_0:CPU_DAP_ENABLE | CCFG_TAP_DAP_1

    CC1352R1: SET_CCFG_CCFG_TAP_DAP_0_PWRPROF_TAP_ENABLE | SET_CCFG_CCFG_TAP_DAP_0_TEST_TAP_ENABLE | SET_CCFG_CCFG_TAP_DAP_0_CPU_DAP_ENABLE | SET_CCFG_CCFG_TAP_DAP_1_AON_TAP_ENABLE | SET_CCFG_CCFG_TAP_DAP_1_PBIST1_TAP_ENABLE | SET_CCFG_CCFG_TAP_DAP_1_PBIST2_TAP_ENABLE

    • Can I simply set them to 0x00 (or whatever value disables them) in the pre-defined symbol section of the project or do I have to put them in a customized ccfg.c file? I checked the driverlib's\ccfg.c file and all settings are combined with a "#ifndef ..." so I assume I could set it either in the pre-defined symbol section or even in the respective opts file?

    Best wishes

    Slev1n

  • Hey Elin,

    since time is a factor for us, since production is going to start next week, I was wondering if these settings are the correct ones. I checked the ccfg.c located in the startup files folder and simply defined all registers within the "Debug access settings" section as 0x00:

    CC1310 - sensor.opts:

    -DSET_CCFG_CCFG_TAP_DAP_0_CPU_DAP_ENABLE=0
    -DSET_CCFG_CCFG_TAP_DAP_0_PRCM_TAP_ENABLE=0
    -DSET_CCFG_CCFG_TAP_DAP_0_TEST_TAP_ENABLE=0
    -DSET_CCFG_CCFG_TAP_DAP_1_PBIST2_TAP_ENABLE=0
    -DSET_CCFG_CCFG_TAP_DAP_1_PBIST1_TAP_ENABLE=0
    -DSET_CCFG_CCFG_TAP_DAP_1_WUC_TAP_ENABLE=0
    -DSET_CCFG_CCFG_TI_OPTIONS_TI_FA_ENABLE=0

    CC1352R1 - collector.opts:

    -DSET_CCFG_CCFG_TI_OPTIONS_TI_FA_ENABLE=0
    -DSET_CCFG_CCFG_TAP_DAP_0_CPU_DAP_ENABLE=0
    -DSET_CCFG_CCFG_TAP_DAP_0_PWRPROF_TAP_ENABLE=0
    -DSET_CCFG_CCFG_TAP_DAP_0_TEST_TAP_ENABLE=0
    -DSET_CCFG_CCFG_TAP_DAP_1_PBIST2_TAP_ENABLE=0
    -DSET_CCFG_CCFG_TAP_DAP_1_PBIST1_TAP_ENABLE=0
    -DSET_CCFG_CCFG_TAP_DAP_1_AON_TAP_ENABLE=0

    Are these registers all I need to set?

    I am also disabling the TI failure access, since I dont think we will need it. Does this cause any issues?

    If there is no mass erase option for the serial bootloader (I only found a simple erase option with an optional start address field) I will unset the defines from the CC1352R1 until we found a solution to implement mass erase within the serial bootloader application.

    Best wishes

    Slev1n

  • Hi Slev1n,

    Thanks for sharing and apologies for the delay. 

    Have you tested the settings you sent and verified that they worked? 

    Thanks, 
    Elin