CC2652R7: Bricked after MassErase: Error -241 @ 0x0. A router subpath could not be accessed. A security error has probably occurred. Make sure your device is unlocked

Hi Morten,

Devices are typically locked if the CCFG configures the CCFG_TAP_DAP_0/1 registers to disallow JTAG.  This is further described in Chapter 11 of the Technical Reference Manual.  Since the CCFG is located in the last page of flash (length of 0x2000 starting at 0xAE000), an incorrect memory map in your project's command linker or the could be causing unexpected CCFG contents.  Can you read the CCFG contents before/after programming, are you able to replicate this behavior on a LP-CC2652R7, is it possible to program a completely different image immediately after the first is successful, and can you recover the device if using a CC26xx/CC13xx Forced Mass Erase in Flash Programmer 2?

Regards,
Ryan

Hi Ryan

   Are you able to replicate this behavior on a LP-CC2652R7

Unfortunately I don't have access to this kit.

   is it possible to program a completely different image immediately after the first is successful

Yes I can program different applications multiple times. The issue occurs always in connection with the MassErase command.

   can you recover the device if using a CC26xx/CC13xx Forced Mass Erase in Flash Programmer 2

I can't get any contact with the device after the issue occur, neither with Flash Programmer 2.

I have tried the suggestions in this thread to unlock:

(+) UNIFLASH: How to use UNIFLASH CLI to Mass Erase CC2652RB with locked debug interface - Bluetooth forum - Bluetooth®︎ - TI E2E support forums

None of it helped until I tried with this command with a default configuration file:

dslite --mode cc13xx-cc26xx-mass-erase -c cc13xx_cc26xx_2pin_cJTAG_XDS200.ccxml
Executing the following command:
> "C:\ti\uniflash_6.3.0\deskdb\content\TICloudAgent\win\ccs_base\DebugServer\bin\DSLite" cc13xx-cc26xx-mass-erase -c cc13xx_cc26xx_2pin_cJTAG_XDS200.ccxml

For more details and examples, please refer to the UniFlash Quick Start guide.

Performing Device Unlock via Mass Erase...
Device Unlocked

It puzzles me that a config file with different target type and JTAG frequency can unlock, when the normally used config file cannot.

Successfully executing commands after changing the JTAG frequency suggests a fault in the stability of the JTAG connection, either the connection itself, wire length, or board design.  You can have the hardware further reviewed through a submission to SIMPLELINK-2-4GHZ-DESIGN-REVIEWS.  What other differences are there in the target configurations that are questionable?

Regards,
Ryan

I'm not sure the JTAG frequency is the full explanation.

I made a copy of my own configuration file, and changed the JTAG frequency to 10.0 MHz. But this file is not possible to unlock a device with:

C:\ti\uniflash_6.4.0>dslite --mode cc13xx-cc26xx-mass-erase -c XDS200_R7conf_10Mhz_nocustom.ccxml
Executing the following command:
> "C:\ti\uniflash_6.4.0\deskdb\content\TICloudAgent\win\ccs_base\DebugServer\bin\DSLite" cc13xx-cc26xx-mass-erase -c XDS200_R7conf_10Mhz_nocustom.ccxml

For more details and examples, please refer to the UniFlash Quick Start guide.

Performing Device Unlock via Mass Erase...
Failed: Connect failed

C:\ti\uniflash_6.4.0>dslite --mode cc13xx-cc26xx-mass-erase -c cc13xx_cc26xx_2pin_cJTAG_XDS200.ccxml
Executing the following command:
> "C:\ti\uniflash_6.3.0\deskdb\content\TICloudAgent\win\ccs_base\DebugServer\bin\DSLite" cc13xx-cc26xx-mass-erase -c cc13xx_cc26xx_2pin_cJTAG_XDS200.ccxml

For more details and examples, please refer to the UniFlash Quick Start guide.

Performing Device Unlock via Mass Erase...
Device Unlocked

In addition, if I try to flash a device with the default configuration, it fails also:

C:\ti\uniflash_6.4.0>dslite -c cc13xx_cc26xx_2pin_cJTAG_XDS200.ccxml -e -f msrModule_CC2652R7_V05.30.xx.skyT0_oad_17012022_production.hex
Executing the following command:
> "C:\ti\uniflash_6.4.0\deskdb\content\TICloudAgent\win\ccs_base\DebugServer\bin\DSLite" flash -c cc13xx_cc26xx_2pin_cJTAG_XDS200.ccxml -e -f msrModule_CC2652R7_V05.30.xx.skyT0_oad_17012022_production.hex

For more details and examples, please refer to the UniFlash Quick Start guide.

DSLite version 11.0.0.2335
Configuring Debugger (may take a few minutes on first launch)...
Initializing Register Database...
Initializing: IcePick_C
Executing Startup Scripts: IcePick_C
Initializing: CS_DAP_0
Executing Startup Scripts: CS_DAP_0
Initializing: Cortex_M3_0
Executing Startup Scripts: Cortex_M3_0
Cortex_M3_0: GEL Output: Memory Map Initialization Complete.
Connecting...
fatal: CS_DAP_0: Error connecting to the target: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00042)
Failed: Operation was aborted

The only difference between the two config files is the target type: "CC1310F128" in the default vs. "CC2652R7" in mine.

Another strange observation is, that when the MassErase (-O MassErase) executes successfully without locking, the device still appear as programmed afterwards (-b BlankCheck --> Device is programmed). Running another successful MassErase, then the device is blank.

I'll try to run some tests with a XDS110 programmer in a while, to se if the behavior is similar.

Best regards

Morten

I will loop in some Tools Team members to further comment on this behavior.  Can you please share the XDS200_R7conf.ccxml configuration file in its entirety?

Regards,
Ryan

If you were able to do an unlock via the command ‘dslite --mode cc13xx-cc26xx-mass-erase -c cc13xx_cc26xx_2pin_cJTAG_XDS200.ccxml’, is this ccxml a copy of the provided \deskdb\content\TICloudAgent\win\ccs_base\arm\ file? This is a special ccxml that allows for connecting to ‘locked’ devices by changing the setting to use ‘cJTAG (1149.7) 2-pin advanced modes’.  Alternately, you can also just run the command ‘dslite --mode cc13xx-cc26xx-mass-erase -d XDS200’, which will pick the right ccxml for you.

Regards,
Ryan

If you were able to do an unlock via the command ‘dslite --mode cc13xx-cc26xx-mass-erase -c cc13xx_cc26xx_2pin_cJTAG_XDS200.ccxml’, is this ccxml a copy of the provided \deskdb\content\TICloudAgent\win\ccs_base\arm\ file? 

Yes, that's the one. The contents of XDS200_R7conf.ccxml are pasted in my first post in the top if the thread.

I did some tests with a XDS110, and by using that programmer the MassErase runs very stable without any locking. Furthermore, with the XDS110, I'm able to turn up the JTAG frequency to around 4MHz before I get connection problems (with XDS200 it happens already at 1.4 MHz)

Then I turned down the JTAG frequency for the XDS200, and it seems that around 400-500 KHz I have a stable MassErase. This will of course slow the MassErase execution, but it does not appear to be much.

Do you have any idea why the MassErase function is more JTAG sensitive than the other operations?

I've forwarded your question for more knowledgeable Team members to address, and you may find further information by researching generic JTAG communication and limitations online.

Regards,
Ryan

Much appreciated, Ryan.

Thanks a lot for your support.

BR Morten