• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 3 answers
  • Subscribers 51 subscribers
  • Views 509 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.

CC2640R2F: CC2640

PRATIK ROY
Prodigy 150 points

Part Number: CC2640R2F
Other Parts Discussed in Thread: UNIFLASH,

I was tinkering with the secure firmware example and the device got bricked.

I took the bin file generated from pwm example code in simple link sdk and converted that to the encrypted bin file, according to the steps given here "secure firmware example".

I flashed the secure bin file using the uniflash at address 0x00000000 and the device got bricked. I need help in recovering the device.

  • 0
    Prodigy 150 points

    Part Number: CC2640R2F

    Help needed on secure firmware example.

    This is the example link of simplink, example.

    I can understand the encryption of simple peripheral secure firmware into a secure bin file and that we flash it at 0x00000000. What I don't understand is what is secure_fw for? why are we flashing that particular firmware at 0x0001F000.

    Thank You.

  • 0 in reply to PRATIK ROY
    TI__Mastermind 25810 points

    Hi Pratik,

    When we encrypt a binary image (simple_peripheral_secure_fw), there must be some code on the device that can verify the downloaded image so it can run it. Otherwise, the binary will not run as it is "unsecure" in the eyes of the application. As stated in the secure_fw README, the secure_fw project is a simple bootloader that verifies the image and runs it.

    The precise location the secure_fw is stored is up to the user and depends on the flash layout. In our example, it should start at 0x0001F000. This will likely be clearer after taking a look at the .map files generated by building both projects.

    For more information, see https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_4_30_00_08/docs/blestack/ble_user_guide/html/ble-stack-3.x-guide/secure-fw-index.html 

    If you are able to flash your board with any unsecure image, then the device is likely not "bricked"; it just cannot load the image since the secure bootloader is not present.

  • 0 in reply to Ammar N
    Prodigy 150 points

    I generated the secure bin file of simple peripheral and flashed it at 0x00000000 and then flashed the secure FW image at 0x0001F000. Now after this, if I try to flash any unsecured firmware at 0x00000000 it should raise an error or device should get bricked right?

  • 0 in reply to PRATIK ROY
    TI__Mastermind 25810 points

    The secure_fw (known as SFB in the link I sent) will erase the image if verification fails and write an error code if this is enabled, otherwise, it will go into a low power mode. The flowchart showing the checks the SFB goes through is in Figure 120.

    I do not use the term "bricked" in my reply as to me this means the device becomes unusable (no new firmware can be flashed on it due to some hardware error). This is not the case here.

  • 0 in reply to Ammar N
    Prodigy 150 points

    I now understand that I need to flash the SFB at 0x0001F000, now can you please guide me to generate a secure bin file for any other project other than simple peripheral secure fw. What exact changes I need to make in a new project to make it a valid image that will be verified by the SFB.

    Thanks a lot Ammar.

    Regards,

    Pratik.

  • 0 in reply to PRATIK ROY
    TI__Mastermind 25810 points

    You should be able to run any binary through the secure_fw_tool.py and it will add the metada accordingly. Have you tried doing so?

    You will likely need to confirm the placement in flash to avoid any overlapping memory space so the secure_fw project can run. As mentioned previously, you should look at the .map files for a better understanding there.

  • 0 in reply to Ammar N
    Prodigy 150 points

    So I can generate any secure bin file from the secure_fw_tool.py and is there:

    • any specific address of placement or at 0x00000000?
    • Do I need modify the ccfg.c file for that firmware or keep it as it is or keep the ccfg off?
    • from .map file I should check that it shouldn't over lap with the secure bootloader or secure_fw project, anything other than that?
    • what should I keep the ccfg.c configuration while flashing the secure_fw at 0x0001F000 to be so that in every possible case I don't brick the device?

    Thanks again!

    Regards,

    Pratik

  • 0 in reply to PRATIK ROY
    TI__Mastermind 25810 points

    Hey Pratik,

    I apologize for the delay, Dallas was hit hard with the winter storm and I was unable to access e2e.

    The ccfg file contains fields used by Boot ROM, startup code, and SW radio stacks to configure chip behavior. You don't need to modify this file. Take a look at the example project in more depth.

    You can also look at our OAD examples for more information on bootloaders and memory layouts.

  • 0 in reply to Ammar N
    Prodigy 150 points

    Thanks a lot Ammar, I hope you are all safe, Thanks a lot for ur responses, I was able to implement the secure firmware.

    God bless you, Take Care.

    Regards,
    Pratik.