CC2650 force bootloader

Luca F

Other Parts Discussed in Thread: CC2650

Hi,

I am developing a custom BLE USB dongle using a FDTI chip for virtual COM and CC2650. My developing platform is SmartRF06EB + CC2650EM-7ID, and I use BLE stack 2.1 with CCS 6.1.

I used HostTest and HostTestStack projects with only some minor changes in HostTest to drive board leds. Everything is working fine and I tested the system with BTool v1.41.05

Now I need to be able to force the ROM bootloader to eventually flash updates of dongle firmware, without using I/O as backdoor since my dongle will not have buttons.

I tried to send the command UTIL_ForceBoot in Btool, but it did not do what I expected, here follows the log.

[1] : <Warning> - 04:53:20.486
This Command Will Invalidate The Image On The Device
Do You Wish To Send The Command?
--------------------------------------------------------------------
[2] : <Info> - 04:53:21.429
User Selected OK
--------------------------------------------------------------------
[3] : <Warning> - 04:53:21.429
Command Sent

There Should Be No Response To This Command
(If There Is A Response -> There Is No BootLoader On The Device)

After Noting That There Is No Response
Start The 'Serial Bootloader' Tool To Download The New Firmware

You May Close BTool Now
<Or>
You Can 'Close Device' Then 'Start Device' In BTool After The Serial Bootloader Is Complete
--------------------------------------------------------------------
[4] : <Tx> - 04:53:21.431
-Type           : 0x01 (Command)
-OpCode         : 0xFE83 (UTIL_ForceBoot)
-Data Length    : 0x00 (0) byte(s)
Dump(Tx):
0000:01 83 FE 00                                     ....
--------------------------------------------------------------------
[5] : <Rx> - 04:53:21.463
-Type           : 0x04 (Event)
-EventCode      : 0x00FF (Event)
-Data Length    : 0x06 (6) bytes(s)
 Event          : 0x067F (1663) (GAP_HCI_ExtentionCommandStatus)
 Status         : 0x02 (2) (Invalid Parameter)
 OpCode         : 0xFE83 (UTIL_ForceBoot)
 DataLength     : 0x00 (0)
Dump(Rx):
0000:04 FF 06 7F 06 02 83 FE 00                      .........
--------------------------------------------------------------------

Reading the documentation I understood that I need to:

1) invalidate the present flash image writing a non-zero value at CCFG_IMAGE_VALID. It means on flash location or just on register IMAGE_VALID_CONF?

2) call HCI_EXT_ResetSystemCmd(HCI_EXT_RESET_SYSTEM_HARD);

Is it supposed that command UTIL_ForceBoot apply 1) and 2) to force boot?

Thanks for your help.

Luca

over 10 years ago

0 Tim C over 10 years ago

TI__Mastermind 34660 points

Hello. In the HostTest proejct, this command is left up to the customer to implement as it will eventually call appForceBoot() will be application dependent:

void appForceBoot( void )
{
  // Dummy function for HCI library that cannot depend on the SBL build defines.
}

You are not going to be able to write to CCFG_IMAGE_VALID from the application as the CCFG is locked at compile-time. In your case, I would recommend connecting an output pin to an input pin that you can use as the bootloader backdoor. Then, in appForecBoot(), assert the bootloader backdoor pin and reset to the bootloader. Please see the TRM for more information: www.ti.com/.../swcu117

Another option is to write a custom bootloader that will run in flash instead of ROM and jump to this bootloader when desired.

0 JXS over 10 years ago

TI__Guru** 105180 points

Hello,

I would agree with Tim. Assuming you haven't locked the last flash sector (page 31) which contains the CCFG, you can erase this sector, then do a reset, such as HAL_SYSTEM_RESET() macro. I would also make sure that you have not placed any app code in page 31, or at least the app code should not be related to the invalidate/reset process.

Best wishes

0 Luca F over 10 years ago in reply to Tim C

Intellectual 355 points

Tim C said:

Hello. In the HostTest proejct, this command is left up to the customer to implement as it will eventually call appForceBoot() will be application dependent:

?

1

2

3

4

void appForceBoot( void )

{

// Dummy function for HCI library that cannot depend on the SBL build defines.

}

You are not going to be able to write to CCFG_IMAGE_VALID from the application as the CCFG is locked at compile-time. In your case, I would recommend connecting an output pin to an input pin that you can use as the bootloader backdoor. Then, in appForecBoot(), assert the bootloader backdoor pin and reset to the bootloader. Please see the TRM for more information: www.ti.com/.../swcu117

Another option is to write a custom bootloader that will run in flash instead of ROM and jump to this bootloader when desired.

Hello Tim,

How can I drive a pin from Stack task? Should I add the PIN driver to the project? Or it is better if I send an inter-task message to application task and drive the pin in that task?

Thanks,
Luca

0 Luca F over 10 years ago in reply to JXS

Intellectual 355 points

JXS said:
Hello,

I would agree with Tim. Assuming you haven't locked the last flash sector (page 31) which contains the CCFG, you can erase this sector, then do a reset, such as HAL_SYSTEM_RESET() macro. I would also make sure that you have not placed any app code in page 31, or at least the app code should not be related to the invalidate/reset process.

Best wishes

Hello JXS,

if I unlock page 31 and erase that sector, my flash image will be definitively invalidated, right? And system will always enter bootloader until I will load a new valid image (VALID FLAG = 0)? Is it correct?

Thanks

Luca

0 JXS over 10 years ago in reply to Luca F

TI__Guru** 105180 points

Hello Luca,

Yes, with CCFG sector erased, the device will always boot into the ROM serial bootloader as the image valid flag will not be set.

Best wishes

Bluetooth®︎

Bluetooth forum

CC2650 force bootloader