• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 53 subscribers
  • Views 677 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.

LP-CC1312R7: CC1312 Locked after failure to load program with UART bootloader.

Javier Pena
Intellectual 285 points
Part Number: LP-CC1312R7
Other Parts Discussed in Thread: CC1312R7, UNIFLASH

Tool/software:

Hello,

I'm in the implementation phase of designing and implementing a bootloader uploader for the CC1312R7, this program has worked well  in the past but sometimes is loses connection during the upload and has to restart the upload, no problem just takes longer.

This has worked well several dozens of times, but yesterday we found a completely locked board after failure to upload the program with the next error when trying to erase the flash:

[2/8/2024 9:02:41] [INFO] Cortex_M3_0: GEL Output: Memory Map Initialization Complete.
[2/8/2024 9:02:45] [INFO] Cortex_M3_0: GEL Output: Memory Map Initialization Complete.
[2/8/2024 9:02:46] [INFO] Cortex_M3_0: MassErase(): Initializing.
[2/8/2024 9:02:46] [INFO] Cortex_M3_0: MassErase(): Issuing Board Reset.
[2/8/2024 9:02:47] [INFO] Cortex_M3_0: MassErase(): Mass erase complete.
[2/8/2024 9:02:50] [ERROR] IcePick_C: Error connecting to the target: (Error -241 @ 0x0) A router subpath could not be accessed. A security error has probably occurred. Make sure your device is unlocked. (Emulation package 9.12.0.00150)

In this program after programming the flash and doing CRC, we configure the CCFG  to lock access to bootloader and make require a mass erase to access it through JTAG and as i said it has worked flawlessly until now. but this board looks completely irrecoverable.

Any idea of how to mass erase the chip and recover the board?, if is it lost we can change solder another MCU but we fear that this happens in production.

I only found this info https://dev.ti.com/tirex/explore/node?node=A__ANoamrIZPWD2-6T-NDDWGg__ccs_devtools__FUz-xrs__LATEST which says under security error: Contact your TI representative for details. So here we are.

Kind regards, Javier

  • 0
    TI__Guru* 81531 points

    Hi Javier,

    Have you tried connectiong the chip to Uniflash and using the Mass erase function there?

    If I understand you correctly you don't have the ROM bootloader enabled in CCFG so you can't use that one to erase the flash.

    Is your bootloader also updating the CCFG area?

    Cheers,

    Marie H

  • 0 in reply to Marie H
    Intellectual 285 points

    Hello Marie,

    Yes, that is the Uniflash log form the mass erase function.

    Our bootloader function updates the CCFG area but in this case the program didn't reach that stage, just updated the FLASH area and bootloader should be accessible but it isn't.

    This is a typical log from our tool for a complete program upload and lock, but as I said we don't lock the JTAG access , as discussed here : https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1322582/cc1312r7-erase-flash-to-blank-state-with-bootloader-and-jtag-access-disabled/5032712?tisearch=e2e-sitesearch&keymatch=%25252520user%2525253A525401#5032712

    T:10:28:18:432-ACK from chip received
T:10:28:19:237-Device in Sync
T:10:28:19:237-Sync OK
T:10:28:19:237-Erasing chip
T:10:28:19:374-ACK from chip received
T:10:28:19:384-Erase chip OK
T:10:28:19:414-ACK from chip received
T:10:28:19:43-Program data info stablished OK
T:10:28:19:461-Total bytes to trasmit: 262144 TotalPackets: 1045
T:10:28:50:893-Program finished
T:10:28:19:46-Program written
T:10:28:50:927-Success:E7970786
T:10:28:50:927-Program CRC_OK
T:10:28:51:065-ACK from chip received
T:10:28:51:082-Bootloader data info stablished OK
T:10:28:51:113-Total bytes to trasmit: 65536 TotalPackets: 262
T:10:28:59:029-Program finished
T:10:28:51:113-Bootloader written
T:10:28:59:062-Success:E7970786
T:10:28:59:062-Bootloader CRC_OK
T:10:28:59:219-CCFG_ID_TI_FA_ENABLE set
T:10:28:59:219-CCFG_ID_PWRPROF_TAP_LCK set
T:10:28:59:219-CCFG_ID_TEST_TAP_LCK set
T:10:28:59:219-CCFG_ID_CPU_DAP_LCK set
T:10:28:59:219-CCFG_ID_AON_TAP_LCK set
T:10:28:59:219-CCFG_ID_PBIST1_TAP_LCK set
T:10:28:59:219-CCFG_ID_PBIST2_TAP_LCK set
T:10:28:59:219-CCFG_ID_BL_BACKDOOR_EN set
T:10:28:59:219-CCFG_ID_BL_ENABLE set
T:10:28:59:219-CCFG_ID_BL_BACKDOOR_LEVEL set
T:10:28:59:201-ACK from chip received

    And the error happened in the main program write at the beginning

    Kind regards, Javier

  • 0 in reply to Javier Pena
    TI__Guru* 81531 points

    Hi Javier,

    Is this on a CC1312R7 Launchpad or a custom board? (Do you think this is a hardware or software issue?)

    Your bootloader, is that in flash or are you using the ROM bootloader?

    Cheers,

    Marie H

  • 0 in reply to Marie H
    Intellectual 285 points

    It is on the  CC1312R7 Launchpad ,We program it with the ROM Bootloader (to program it with UART) the Flash which includes a MCU bootloader and the main program.

    We have solved it soldering another CC1312R7 we had available to recover the board so it was software for sure and my assumption it that it was locked in some way.

    Kind Regards , Javier.

  • 0 in reply to Javier Pena
    Intellectual 285 points

    Today the issue happened again, same problem during program upload the connection was lost and when we tried to program it again with Uniflash or the ROM bootloader it was completely locked.

  • 0 in reply to Javier Pena
    TI__Guru* 81531 points

    Hi Javier,

    Do you start or end with programming the CCFG? If you're worried about an unstable connection it may be a good idea to start with CCFG, so you won't be locked out of the device?

    Do you need help debugging why the connection is lost?

    Cheers,

    Marie H

  • 0 in reply to Marie H
    Intellectual 285 points

    I end with the CCFG configuration after CRC of both bootloader and main program. Once this has been verified the program continues so I doubt that is a CCFG problem. It is true that this can be a unstable connection problem in some specific cases in case of an incorrect CRC or timeout the program erases the flash and tries again.

    In any case my suspicion is that for unknown reasons our computer program treats the timeout of ack of the ROM bootloader as a reasons to resent that packet while in reality the bootloader did sent this ack packet continuing the download process, but first thing is COMMAND_DOWNLOAD which indicates the bootloader the writing size and should avoid writing in the CCFG area with a normal write command.

  • 0 in reply to Javier Pena
    TI__Guru* 81531 points

    Hi Javier,

    We recently updated our host implementation in the Serial Bootloader app, maybe it's worth taking a look?

    https://www.ti.com/lit/swra466 

    Cheers,

    Marie H