• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 53 subscribers
  • Views 2092 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.

CC1310 ti bootloader protection

Steve Corbin
Prodigy 90 points
Other Parts Discussed in Thread: CC1310

Since the only way to protect the cc1310 processor to be read, is to disable the ti bootloader in the CCFG area

1) After we disable the TI Boot, can we internally read the CCFG area in ram and enable back the ti boot, the flash block and write back the CCFG area?

2) After this we should be able to connect with the TI Boot?

3) Do you have better solution to provide that will allow me to lock my processor to be read and that I can unlock if needed to reprogram it?

3) Are you planning to add a ID code to the back door functionality, with this we could leave the ti boot enabled and access it using the back door and providing the ID code? Ir would be much more useful for manufacturing product with the cc1310 on it?

  • 0
    TI__Intellectual 1380 points

    Hi Steve,

    1) No, writing to the CCFG area is very discouraged because a power loss after erase or during a write could easily end up leaving the device in a state where you are totally locked out and/or where it won't run.

    2) Yes, but don't do this because of the reason above.

    3) No, there is no granularity to access control to the bootloader, it's all or nothing. What you can do is keep mass-erase available, then you can signal this via the JTAG, and then reprogram it. No reading out though.

    4) Not really, but we are looking into making a secure bootloader for future devices. Nothing has yet to be decided.

    What you should do is to implement a minimal second stage bootloader yourself. This way you can use the first stage bootloader (or JTAG) in production to load, and protect, the second stage bootloader. This in turn can be freely configurable by you.

    The upside of this is that you can have the second stage bootloader implement secure signing of images, use whatever protocol you want to program the chip and also move around all IO's used for the bootloader freely.

    Best regards,
    Niklas