TMS320F2800156-Q1: Trouble Setting Breakpoint with the Action "Remain Halted" at 0x8058

Hi Shuqing,

Shuqing Zhou said:

1. What are the possible causes of this phenomenon and how can we locate the problem?

There are two warning messages in the console that are interesting: "Failed unlocking device (zone 1) after reset." and "Failed unlocking device (zone 2) after reset."

Is the device locked? Can you now read any of the flash memory addresses? If they are showing as all FFFF or 0000, then the device is likely secured. You can also directly check the UNSECURE bit in Z1_CR and Z2_CR registers to be more certain. 

Also, are you/have you programmed the OTP to change the device boot configuration?

Shuqing Zhou said:

2. Could you help to check is it XRSn circuit be ok or not?

Can you scope into the XRSn pin to see if it behaving correctly? If it is due to XRSn design or board manufacturing defects, you can also confirm this is the case by testing the same program on a ControlCARD.

Shuqing Zhou said:

m modify the demo based on flashapi_ex1_programming project, it need to change the cmd file, I want to check if we have any demo that run in ram but erase, program the flash? Or do you have any suggestion when i modify the flashapi_ex1_programming project?

The SCI/CAN flash kernel examples may fit that requirement as they execute in the RAM and erase/program the flash.

Best,

Matt

Hi Matt,

Thanks for your suggestion, I checked them FLASH data, and all of it is 0 and I checked customer Z1_CR/Z2_CR register and the value is 0x80000, that means this chip be locked permanently. But customer confirmed that they don’t used DCSM in their development and I check with them project, that don’t have DCSM.asm and related content in their CMD.

And they told that they don’t meet the error when they program the .out file using CCS. They just have possibility to meet this when they program the hex using Uniflash, and it not be happened in every board, so I think it may not their project to modify the OTP. And I think it may be their improper operation of Unilfash.

In TRM, we can see that chip be blocked permanently may be caused by below reason:

1.

2.

Now they can connect the debugger successfully, but can’t be programmed, I’m not sure if above situation will have same phenomenon with customer.

So,

1. Could you help to answer what reason may cause chip be blocked permanently but debugger can be connected?
2. What the related operation in Uniflash about this case?

Hi Shuqing,

I am continuing to consult multiple experts on this issue and was unable to replicate with an F2800157 device.

How are you generating the hex file?

Best,

Matt

Hi Matt,

They use CCS12.7.1, and the hex2000 configuration is show in below:

ccs.jfif

Wha's more, could you tell me what will cause chip be blocked permanently but debugger can connect in addition I mentioned above? What operation need to do in uniflash?

BRs

Shuqing

Hi Shuqing,

JTAG will still have access to unsecure resources, hence why UniFlash is able to connect. You need to provide a password (CSMKEY) to unlock the protected DCSM zones (unless the CSMPSWD is ALL_0). Can you verify the contents of the CSMPSWD to be all 0?

If the device is permanently locked by accident, like by power loss during flash programming, then it can not be disabled. If there is an issue with the hex file (something is mapped to the password location) then you need to correct the linker cmd file (use type = DSECT) so that nothing gets programmed into password locations. See this guide for more details: https://software-dl.ti.com/ccs/esd/documents/sdto_cgt_linker_special_section_types.html

Best,

Matt

Hi Matt,

CSMPSWD is not all 0, but we can't use it to unlock the chip also. We use the on-chip tools.

3302.webwxgetmsgimg.jfif

Matt Kukucka said:

If the device is permanently locked by accident, like by power loss during flash programming, then it can not be disabled

You mean when power loss happen during flash programming, it may lock chip even customer don't program the OTP?

What any other reason may lock the chip permanently?

I program the hex file(customer program to them chip) to evm, that don't lock my chip, so I don't think hex file will lock the chip.

BRs

Shuqing

Hello Shuqing,

The screenshot attached only shows Z1_CSMKEY (the password you have to enter to unlock the device), not Z1_CSMPSWD. However, value of Z1_CR supports that the CSM Passwords are all zero and the device is permanently locked, as you mentioned above.

More details on locking and unlocking a device is explained here: https://www.ti.com/video/6336139910112

Shuqing Zhou said:

You mean when power loss happen during flash programming, it may lock chip even customer don't program the OTP?

Yes, this is possible.

Can you share the linker command file and map file for the project?

Best,

Matt

Hi Matt,

This is the hex file: 

hex.txt

BRs

Shuqing

Hello,

Shuqing Zhou said:

If they program the .out file to chip using CCS12.7.1 and XDS110, everything will be ok.

If you program the same .out file using UniFlash, is that ok also? Or do you have the same issue?

Can you also provide the *.out file?

Thanks

ki

Hi Ki,

This is not happen every time. So I’m not sure if we use uniflash to program the out file whether it will cause program.

I want to know what operation may lock chip when we use uniflash? I can take this check list to check with customer firstly 

BRs

Shuqing

Hi Matt and Ki, 

I also upload their cmd file:

MEMORY
{
   BEGIN            : origin = 0x00080000, length = 0x00000002
   BOOT_RSVD        : origin = 0x00000002, length = 0x00000126

   //RAMM0_Noclr  : origin = 0x00000128, length = 0x00000008
   RAMM0            : origin = 0x00000128, length = 0x000002D8
   //RAMM0            : origin = 0x00000130, length = 0x000002D0
   RAMM1            : origin = 0x00000400, length = 0x000003F8
   // RAMM1_RSVD       : origin = 0x000007F8, length = 0x00000008 /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

   RAMLS0_Noclr     : origin = 0x00008000, length = 0x00000008
   //RAMLS0           : origin = 0x00008000, length = 0x00002000
   RAMLS0           : origin = 0x00008008, length = 0x00001FF8
   RAMLS1           : origin = 0x0000A000, length = 0x00001FF8
   // RAMLS1_RSVD      : origin = 0x0000BFF8, length = 0x00000008 /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

   RESET            : origin = 0x003FFFC0, length = 0x00000002

   /* Flash sectors */
   FLASH_BANK0_SEC_0_7     : origin = 0x080002, length = 0x1FFE  /* on-chip Flash */
   FLASH_BANK0_SEC_8_15    : origin = 0x082000, length = 0x2000  /* on-chip Flash */
   //FLASH_BANK0_SEC_16_23   : origin = 0x084000, length = 0x2000  /* on-chip Flash */
   //FLASH_BANK0_SEC_24_31   : origin = 0x086000, length = 0x2000  /* on-chip Flash */
   //FLASH_BANK0_SEC_32_39   : origin = 0x088000, length = 0x2000  /* on-chip Flash */
   //FLASH_BANK0_SEC_40_47   : origin = 0x08A000, length = 0x2000  /* on-chip Flash */
   //FLASH_BANK0_SEC_48_55   : origin = 0x08C000, length = 0x2000  /* on-chip Flash */
   //FLASH_BANK0_SEC_56_63   : origin = 0x08E000, length = 0x2000  /* on-chip Flash */
   //FLASH_BANK0_SEC_64_71   : origin = 0x090000, length = 0x2000  /* on-chip Flash */
   //FLASH_BANK0_SEC_72_79   : origin = 0x092000, length = 0x2000  /* on-chip Flash */
   //FLASH_BANK0_SEC_80_87   : origin = 0x094000, length = 0x2000  /* on-chip Flash */
   //FLASH_BANK0_SEC_88_95   : origin = 0x096000, length = 0x2000  /* on-chip Flash */
   //FLASH_BANK0_SEC_96_103  : origin = 0x098000, length = 0x2000  /* on-chip Flash */
   //FLASH_BANK0_SEC_104_111 : origin = 0x09A000, length = 0x2000  /* on-chip Flash */
   //FLASH_BANK0_SEC_112_119 : origin = 0x09C000, length = 0x2000  /* on-chip Flash */
   //FLASH_BANK0_SEC_120_127 : origin = 0x09E000, length = 0x1FF0  /* on-chip Flash */
   // FLASH_BANK0_SEC_127_RSVD : origin = 0x0A0FF0, length = 0x0010  /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

}


SECTIONS
{
    codestart        : > BEGIN

   .text            : >> FLASH_BANK0_SEC_0_7 | FLASH_BANK0_SEC_8_15 , ALIGN(16)

   .cinit           : > FLASH_BANK0_SEC_8_15, ALIGN(16)
   .switch          : > FLASH_BANK0_SEC_8_15, ALIGN(16)

   .reset           : > RESET,  TYPE = DSECT /* not used, */

   .stack           : > RAMM1
 Noclear_Data    : > RAMLS0_Noclr,TYPE = NOINIT
#if defined(__TI_EABI__)
   .bss             : > RAMLS0|RAMLS1, ALIGN(8)

   .bss:output      : > RAMLS0
   .init_array      : >> FLASH_BANK0_SEC_0_7, ALIGN(16)
   .const           : >> FLASH_BANK0_SEC_0_7, ALIGN(16)
   .data            : > RAMLS0
   .sysmem          : > RAMLS0
  .bss:cio          : > RAMLS0
#else
   .pinit           : >> FLASH_BANK0_SEC_0_7, ALIGN(16)
   .ebss            : > RAMLS0
   .econst          : >> FLASH_BANK0_SEC_0_7, ALIGN(16)
   .esysmem         : > RAMLS0
   .cio             : > RAMLS0
#endif

#if defined(__TI_EABI__)
    GROUP
    {
       .TI.ramfunc
       { -l FAPI_F280015x_EABI_v2.00.10.lib}

    }LOAD = FLASH_BANK0_SEC_0_7,
                      RUN = RAMLS0,
                      LOAD_START(RamfuncsLoadStart),
                      LOAD_SIZE(RamfuncsLoadSize),
                      LOAD_END(RamfuncsLoadEnd),
                      RUN_START(RamfuncsRunStart),
                      RUN_SIZE(RamfuncsRunSize),
                      RUN_END(RamfuncsRunEnd),
                      ALIGN(16)
#else
      GROUP
    {
       .TI.ramfunc
       { -l FAPI_F280015x_EABI_v2.00.10.lib}

    } LOAD = FLASH_BANK0_SEC_0_7,
                      RUN = RAMLS0,
                      LOAD_START(_RamfuncsLoadStart),
                      LOAD_SIZE(_RamfuncsLoadSize),
                      LOAD_END(_RamfuncsLoadEnd),
                      RUN_START(_RamfuncsRunStart),
                      RUN_SIZE(_RamfuncsRunSize),
                      RUN_END(_RamfuncsRunEnd),
                      ALIGN(16)
#endif

    /*  Allocate IQ math areas: */
   IQmath           : > FLASH_BANK0_SEC_8_15, ALIGN(16)
   IQmathTables     : > FLASH_BANK0_SEC_8_15, ALIGN(16)
}

Shuqing Zhou said:

I want to know what operation may lock chip when we use uniflash?

Matt - can you answer this one?

Hi Matt,

Add more information: I check the memory, all the OTP and flash data is zero; and the Z1DCSM register show in below:

DCSM1.jfif

I don't know why LINKPOINTER change to 0xFFFFC000, is it because chip be locked permanently?

And one thing is strange: even if the chip is locked, CPU access is not be locked, that means we can run app(although the APP may run away). But I find customer's app don't run into flash, and I connect the debug and load the symbol of BOOTROM, it shows code is stuck in below position(0x3fb709~3fb711):

BRs

Shuqing