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:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/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.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/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:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/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

Hi Shuqing,

To keep you updated -- we've brought up this issue with the UniFlash team to see what may be causing the hex program load to lock the device.

Shuqing Zhou said:

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):

That is unusual. I will reach out to the boot ROM expert for this device to see if that's expected for when the Flash is locked.

Shuqing Zhou said:

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

I will also be attempting to reproduce this issue on my end as soon as I get the parts, but can you try replicating it again in UniFlash and monitoring the XRSn signal? If so, please send a screenshot of the oscilloscope of XRSn for when it occurs.

Best,

Matt

Hi Matt,

I must to update, a case happeed again, and customer use CCS to program, CCS configuration can be seen: https://tidrive.ext.ti.com/a/Zo4ZSysOGUZ0jhlW/3bc24111-9c1d-4e9e-be92-bbd5c1f5d3ef?l

What's more, code also stuck in 0x3fb709~3fb711, they don't monitor the XRSn when they programming even through I ask them to do that.

BRs

Shuqing

Hi Shuqing,

Please allow me some time to look over the CCS configuration. In the meantime, please advise the customer to monitor the XRSn line during programming and screenshot what is happening when it fails.

Next Monday, I'll discuss what could be causing the device to be stuck in the boot ROM with a colleague. I've also ordered parts to replicate the issue and will try to replicate once I receive them, but that could take weeks.

Best,

Matt

Hi Matt,

I will let customer monitor the XRSn, and hope you can answer why code stuck in BOOTROM today, thanks.

BRs

Shuqing

Hi Shuqing,

I'm still waiting to hear back from my colleague about the boot ROM, but I have input from the UniFlash team:

"In the first screenshot, the binary checkbox is on. For hex loads, that checkbox should be off by default. Maybe the user turned on binary load manually, which then turns it to a binary load instead of a hex load. The address field isn’t specified, so I think UniFlash tries to load to address 0x0, and writes to memory locations that are not accessible and therefore they are getting that initial error in the console. However, I don’t think the file is big enough to write to the security fields memory locations, so I’m not sure why the device would get locked up after that.

Anyways, the recommendation is to make sure they have that binary checkbox off in UniFlash."

I'll also note that since loading a program via CCS locks the device with the same error, it must not be a problem with how CCS/UniFlash loads the device. Can the customer please share their project's .map file?

Best,
Matt

Hi Shuqing,

To keep you updated with what's been done:

1. I've received all the parts and attempted to replicate the customer's issue with the hex file you provided. I've been able to successfully flash the program onto the device, even performing an XRSn during programming, but was unable to reproduce the issue.
2. I've been discussing the issue with the boot ROM expert, who's verifying information with the flash team about the 1T/2T ready signal issue the customer is seeing.

Best,

Matt

Do you have any updates on this issue? Was a resolution determined?