• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 1617 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.

Flash lock protection bits

Jason wang57589
Prodigy 20 points

we have a couple of products using CC1110F32.  we found sometimes last page sometimes all pages of the flash was erased. So we want use the flash protection bit.

In the datasheet: "The lock protect bits are written as a normal flash write to FWDATA, but the Debug Interface needs to select the Flash Information Page first instead of the Flash Main Page which is the default setting. The Information Page is selected through the Debug Configuration which is written through the Debug Interface only. Table 44 defines the byte containing the flash lock protection bits. Note that this is not an SFR, but instead the byte stored at location 0x000 in Flash Information Page."

1.  I couldn't select information page by using WR_CONFIG(IN: config_8).

Before write, RD_CONFIG()=0

After WR_CONFIG(1), RD_CONFIG() still is 0. if I erase the page, my firmware will be erased. this mean still in Main page.

2. If I can select Flash Information Page, do I need erase the page first(as normal flash write) before write the protection bit?

anybody have an example code to write the protection bit?

 

 

  • 0
    TI__Genius 10955 points

    What tool are you using for flashing the image? For instance, the Smart RF flash programmer has the ability to set the flash protection bits when writing an image. Also, using the debugger in IAR gives this opportunity (See Project->Options->Debugger->Texas Instruments). I believe most third-party tools also have the ability to set flash lock bits when flashing an image.

  • 0 in reply to hec
    Prodigy 20 points

    Thanks, the progrmmer tool we used is built by ourself  by modifying one of our CC1110 product board. Now it works.

  • 0 in reply to hec
    Prodigy 150 points
    I too have seen the flash come back erased in a microcontroller contained within one of our products. The product and the mircocontroller worked fine for months and then one day the customer calls for service stating the product is non-responsive. There is no way the customer had access to the microcontroller while in their possession, which can only mean the CPU exhibited erratic behavior and erased the flash. In this case just the boot block sector of the flash was erased to all FF's while other flash sectors were still intact, so I'm not considering it to be an environmental event. There are no flash write routines within the code.

    My questions is: Setting the flash protection bits enable protection from modification using a debugger or flash tool, but do they protect the flash from a run-away CPU?