• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 53 subscribers
  • Views 893 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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/CC1310: CCFG settings for production

Slev1n
Genius 5680 points
Part Number: CC1310

Tool/software: Code Composer Studio

Hey guys,

I stumbled over a hint in the CC1310 manual stating, that some settings should be performed in the CCFG area for production (see below). I do now have some questions.

1. We do currently not use OAD, thus I agree with point 1, that the bootloader and its backdoor should be disabled. However, what could happen if it is not disabled?

2. Regarding the CCFG_DAP_TAP register mentioned in point 3, is the device bricked if flashed with the registers set to 0x00 or is there still a way to connect to it via JTAG (we use the TIDA 00489, thus the CC1310 can only be reached via JTAG)

3. There is more than one CCFG_DAP_TAP_1 register, however, which one is referred to in point 4?

4. If we decide to change the CCFG settings, should this be done via the projects pre-defined symbol section? Because if we alter the ccfg.c file within the startup-folder, we would change the settings for all projects, right?

Best wishes

Slev1n

  • 0
    TI__Guru**** 317180 points

    The answer will depend on the usage of the product.

    If you don't change settings in CCFG you can risk that someone change the code on the DUT in the field. Most customers also want to disable the possibility to read out the code  from flash to protect their IP. Hence the list in "9.1 Customer Configuration (CCFG)" is added as a "how to" for those who want to protect the device. 

    These settings are typically set in mass production when you don't want to access the DUT after that point. If you disable JTAG it should still be possible to do a mass erase

    Should only be one CCFG_TAP_DAP_1 on offset FE8h

    It is possible to use a project dependent CCFG. If you open one of the examples in the SDK, open the CCFG.c file in the example and you can find a description on how to do this in this file. 

  • 0 in reply to TER
    Genius 5680 points

    Hey TER,
    thanks for the reply.

    TER said:

    If you don't change settings in CCFG you can risk that someone change the code on the DUT in the field. Most customers also want to disable the possibility to read out the code from flash to protect their IP. Hence the list in "9.1 Customer Configuration (CCFG)" is added as a "how to" for those who want to protect the device. 
    These settings are typically set in mass production when you don't want to access the DUT after that point. If you disable JTAG it should still be possible to do a mass erase

    I understand, that these settings are for protection and we would like to do this as well in the near future. I just wonder, if something during the flash process within the production line happens and for example the verification fails. Could the device be flashed again or is it bricked?

    Basically we would like to protect our device since we are not going to interface it after production but we are afraid to brick the device if something goes wrong during production. Besides, does any of this setting interfere with OAD flashing?


    TER said:
    Should only be one CCFG_TAP_DAP_1 on offset FE8h
    #define DEFAULT_CCFG_CCFG_TAP_DAP_1      ( \
	 ((((uint32_t)( SET_CCFG_CCFG_TAP_DAP_1_PBIST2_TAP_ENABLE        )) << CCFG_CCFG_TAP_DAP_1_PBIST2_TAP_ENABLE_S        ) | ~CCFG_CCFG_TAP_DAP_1_PBIST2_TAP_ENABLE_M        ) & \
	 ((((uint32_t)( SET_CCFG_CCFG_TAP_DAP_1_PBIST1_TAP_ENABLE        )) << CCFG_CCFG_TAP_DAP_1_PBIST1_TAP_ENABLE_S        ) | ~CCFG_CCFG_TAP_DAP_1_PBIST1_TAP_ENABLE_M        ) & \
	 ((((uint32_t)( SET_CCFG_CCFG_TAP_DAP_1_WUC_TAP_ENABLE           )) << CCFG_CCFG_TAP_DAP_1_WUC_TAP_ENABLE_S

    Do you mean this definition?

    TER said:
    It is possible to use a project dependent CCFG. If you open one of the examples in the SDK, open the CCFG.c file in the example and you can find a description on how to do this in this file. 

    Ah thank you, I found it.

    best wishes

    Slev1n

  • 0 in reply to Slev1n
    TI__Guru**** 317180 points

    If you have disabled the JTAG interface and the possibility to do mass erase you have bricked the device in the sense that you are not able to access it and change the code.

    No, what you are referring to is part of the code in the CCFG.c file. I was referring to the register definition in chapter 9 in https://www.ti.com/lit/pdf/swcu117

  • 0 in reply to TER
    Genius 5680 points

    TER said:
    If you have disabled the JTAG interface and the possibility to do mass erase you have bricked the device in the sense that you are not able to access it and change the code.

    Ok, this makes sense. But regarding OAD, I would expect that the bootloader and backdoor have to be enabled to allow re-flashing the device with a new firmware, thus, disabling them wont work in OAD scenario, right?

    best wishes

    Slev1n

  • 0 in reply to Slev1n
    Genius 5680 points

    Hey, TER it has been a while, my last question regarding OAD from my last post is still pending, as we are still wondering if OAD is working if we disable backdoor access to bootloader.

    best wishes

    Slev1n

  • 0 in reply to Slev1n
    TI__Guru**** 317180 points

    Are you using on-chip or off.-chip OAD?

    Either way I believe that disable bootloader should be ok since the new image will be transfered through SPI and hence not impacted by the bootloader setting.

  • 0 in reply to TER
    Genius 5680 points

    It will be off-chip OAD since we use the CC1310 chip at the beginning. In future maybe on-chip with cc1352R1 could be of interest.