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.

CCS: Unable to connect to target (TMS320F28335) after changing CSM password.

Guru 19925 points
Other Parts Discussed in Thread: UNIFLASH, TMS320F28335

Tool/software: Code Composer Studio

Hello,

I can unlock the micro using C2Prog.exe; however, after  the micro is locked, I am not able to connect to the target using the XDS100v2 debugger.

According to SPRU963A (Page 23), there are two ways to connect an emulator (e.g. XDS100v2) to the target after the target has been locked:

1.  Use the use the “Branch to check boot mode” boot option.

      My hardware doesn't have the switches to set the Branch to check boot mode” boot option.

2.  Use the Wait-In-Reset emulation mode.

I set EMU1 to high and EMU0 to low in the Advanced Target Configuration (see Below) and  programmed the device with a password other than all ones .   After doing so and resetting the device, I am still not able to connect (see connection error dialog box below).  

What am I doing wrong?

Stephen

  • Stephen,

    I don't have F28x hardware with me right now, but I suspect you will have to also enable the option below to force the device to sample the EMU pins while connecting.

    There is also another thread where another option is discussed, but I can't tell exactly the outcome as I can't access the image files at the dropbox locations.

    https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/493016

    Hope this helps,

    Rafael

  • Ok, I tried that and it didn't work.

    Here are all my project's relevant debug settings:

  • Hello,

    It looks like Rafael is off or busy today.

    Is anyone else at TI able to help me with this issue.

    Thanks,
    Stephen
  • Hello,

    After recycling power to the target, the target halts (as shown by an led on the pcb that indicates whether the target is running or not).

    However, I still get the -1015 error when I try to connect with the XDS100v2.

    Both EMU pins are tied high externally.

    What else should I try?

    Thanks,
    Stephen

  • I tried using the newest UniFlash and information from and that does't work.

    I also tried a TMS320F28335 Control card on a USB-EMU [R2] docking station and that doesn't work.

    Is anyone looking into this?

    Stephen

  • Stephen,

    Please apologize for the delay; I was in and out of the office this past week.

    I was able to consistently connect o my F28335 eZdsp board without having to change the boot mode via jumpers. The critical part I realized (and mentioned before) is that the device has to sample the EMUn pins status at boot time. However, the reset option I mentioned did not work for me as well - most probably because it issues a soft reset that does not sample the pins. 

    I created a short clip showing what I did to connect to my locked target. I start from a completely powered off environment (both the XDS100v2 and the board) and, as I power up each element, I show the response of the Test Connection to illustrate the steps. 

    I then launch the target and the first attempt to connect will set the EMUn pins as configured by the target configuration file. I then power cycle my board and was able to connect to it without problems. I was able to do this repeatedly. 

    Please let me know if this works for you. 

    Regards,

    Rafael

  • Ok, I tried that and that still doesn't connect.

    I did the following:
    1. apply power to the target.
    2. Plug in the XDS100v2 to the usb port.
    3. Select Debug (I had already selected the correct options and set the password in the debug configuration) to debug the target.
    4. Wait for the dialog box to say it won't connect.
    4. recycle power to the target
    5. Select Debug again


    On the Configuration Target tab, do you check both of the following:
    - Reset the target on program load or restart
    - Restart the target on a symbol load as well as a program load

    Stephen
  • At time 0:47 in the video after you press Debug and the Debug Configuration dialog disappears, I notice the Test Connection button is pressed again.

    Is that correct? It happens very quickly. What is happening at that time?
  • I also went through each of your steps:
    1. Try to connect with the power removed from the target.
    2. Apply power to the target and try to connect.
    3. Bring up the debug configuration and make sure all the settings are correct.
    4. Press Debug.
    5. The XDS100v2 tries to connect to the target and fails.

    Why does your debug configuration only launch the debugger instead of connecting right away?

    Stephen
  • The target is halting after recycling power, so the EMU pins are working properly.
  • Stephen,

    >>On the Configuration Target tab, do you check both of the following:
    >>- Reset the target on program load or restart
    >>- Restart the target on a symbol load as well as a program load
    Both options are disabled, but in my case these options wouldn't matter as I am not loading any code but instead simply connecting to a running target.

    >>At time 0:47 in the video after you press Debug and the Debug Configuration dialog disappears, I notice the Test Connection button is pressed again.
    Perhaps the screen capture software showed an artifact, but at this time the debugger was launching and I did not press the Test Connection button.

    >>Why does your debug configuration only launch the debugger instead of connecting right away?
    I am using a Debug configuration that is not tied to a project, therefore the debug launch is completely manual - i.e., it requires you to perform each and every step of the way.

    One detail I noticed is that, if I tried to launch a debug configuration tied to a project on this same device, the process failed during the connect phase, as it tried to load code but the device was not properly connected (it required a hard reset to sample the EMUn pins).

    I will keep trying a few additional things to see how the process can be improved.

    Regards,
    Rafael
  • I got it to work. I put the target in boot loader mode (serial port boot loader) and also I set the EMU settings back to disabled.

    I first launched the debug (view->target configurations and then selected and launched the configuration) and then I was able to connect (i.e. right click and selected connect target). I recycled power to the target several time and each time it connected.

    Did you have your target in boot loader mode during your test?  Should I expect it to work all the time?

    Stephen

  • Although your steps seem correct, there not working with my setup. I can see that the target is halted after I recycle power. After that, I launch the debug configuration and then I try to connect (i.e. Connect Target). It doesn't connect and immediately starts running.

  • Ok, I was wrong.. what I did didn't work. It only allowed me to connect to the boot loader code.
  • Stephen,

    >>Did you have your target in boot loader mode during your test? Should I expect it to work all the time?
    I tested a variety of boot modes (Flash, SPI, etc.) with the same outcome - obviously the "wait on boot" mode always works.

    >>Although your steps seem correct, there not working with my setup. I can see that the target is halted after I recycle power. After that, I launch >> the debug configuration and then I try to connect (i.e. Connect Target). It doesn't connect and immediately starts running.
    If I understood correctly your procedure, after the target is halted you should instead simply load either code or symbols (menu Run --> Load --> Load Program or Load Symbols), given that launching a debug configuration at this point with the target already connected will undo all the steps.

    Details are here: processors.wiki.ti.com/.../GSG:Connecting_to_slave_cores_in_SoC_devices_v5

    >> It only allowed me to connect to the boot loader code.
    If you are seeing the bootloader code it means it is working, given the the password lock blocks all JTAG accesses.

    Regards,
    Rafael
  • Here's all my steps showing the settings:

    - A Target Configuration file named "G8TargetDebugConfiguration.ccxml" is in the project folder.
    - A Debug Configuration named "G8TargetDebugConfiguration.ccxml" (in Run->Debug Configurations) is configured as shown below (see images).
    - In the Target Configuration file advanced settings, I set both JTAGE nTRST Boot-Mode and The Power-On-Reset Boot-Mode to EMU1 is high, EMU0 is low and clicked Save.
    - I recycle power to the target and then I select "Test Connection" from G8TargetDebugConfiguration.ccxml advanced settings.
    - Then, I recycle power to the target again. An lit LED on the target board shows that the Target is not running (i.e. halted).
    - Next, I right click on Projects->G8->G8TargetDebugConfiguration.ccxml (in view->Target Configurations) and select Launch Selected Configuration.
    - From the debug window, I right click on the Disconnected Target and select Connect Target.



  • I attached the password.asm file containing the password.

    I am able to unlock the flash using C2Prog.exe with the password contained in password.asm.

  • Hello Rafael,

    I missed your previous post before I posted this morning.  Please look over my settings and the steps I use.

    >>If I understood correctly your procedure, after the target is halted you should instead simply load either code or symbols (menu Run --> Load --> Load Program or Load Symbols), given that launching a debug configuration at this point with the target already connected will undo all the steps.

    I haven't connected the debugger to the target yet.  After I recycle power, a lit LED on the PCB tells me the target is halted. 

    >>If you are seeing the bootloader code it means it is working, given the the password lock blocks all JTAG accesses. 

    It may work in in the bootloader code, but it's not working for boot to flash mode.

    How can I debug this issue?  I am using CCS v6.2 and TI Emulators v6.0.628.1.

    Stephen

  • Hello Rafael,

    Is there anything else I should check?

    Stephen
  • Stephen,

    stevenh said:

    Here's all my steps showing the settings:

    - A Target Configuration file named "G8TargetDebugConfiguration.ccxml" is in the project folder.
    - A Debug Configuration named "G8TargetDebugConfiguration.ccxml" (in Run->Debug Configurations) is configured as shown below (see images).
    - In the Target Configuration file advanced settings, I set both JTAGE nTRST Boot-Mode and The Power-On-Reset Boot-Mode to EMU1 is high, EMU0 is low and clicked Save.
    - I recycle power to the target and then I select "Test Connection" from G8TargetDebugConfiguration.ccxml advanced settings.
    - Then, I recycle power to the target again. An lit LED on the target board shows that the Target is not running (i.e. halted).
    - Next, I right click on Projects->G8->G8TargetDebugConfiguration.ccxml (in view->Target Configurations) and select Launch Selected Configuration.
    - From the debug window, I right click on the Disconnected Target and select Connect Target.

    The procedure I am doing differs from yours on the following:

    - I have a project-independent target configuration file. This guarantees the Debug Configuration is truly independent - i.e. will not try to load anything behind the scenes. Perhaps you could try this?

    - After executing step 7 I power cycle the board and try to connect again. Obviously that I don't have an LED that tells me if the target is halted or not, but in my case I can't tell for sure if the JTAG debug probe is somehow released after the "Test Connection" ends and therefore I need to guarantee the EMUn pins are properly sampled. Perhaps you could skip the "Test Connection" phase and try it this way? 

    - I don't know if you told me which boot mode your device is trying to use. Perhaps this may make a difference on the outcome I am getting here.  

    Regards,

    Rafael

  • - I have a project-independent target configuration file. This guarantees the Debug Configuration is truly independent - i.e. will not try to load anything behind the scenes. Perhaps you could try this?
    I have already tried that. As you can see by the debug configuration images in one of my previous post, the Program and Project are both are empty on the debug configuration's Program tab. I also, moved the target configuration file to the desktop and pointed the debug configuration to that target configuration file. I tried it again and It still doesn't work.

    >>- After executing step 7 I power cycle the board and try to connect again. Obviously that I don't have an LED that tells me if the target is halted or not, but in my case I can't tell for sure if the JTAG debug probe is somehow released after the "Test Connection" ends and therefore I need to guarantee the EMUn pins are properly sampled. Perhaps you could skip the "Test Connection" phase and try it this way?

    After step 7, I power cycled and tried it again. After the power cycle, the LED was lit (i.e. target halted). It still doesn't work. If the LED is not lit, the program is running. I measured the EMU0 and EMU1 pins with an oscillocscope after the power cycle. EMU0 was 400mV and EMU1 was 3.3V, Externally, EMU0 and EMU1 are tied to 3.3V through 4.7kOhm resistors.

    >>- I don't know if you told me which boot mode your device is trying to use. Perhaps this may make a difference on the outcome I am getting here.

    For the steps above, I was using jump to flash boot mode. I can only put the target into two boot modes: jump to flash and SCI-A boot.

    Stephen

  • Steven,

    Are you able to connect to device but not able to run the code when device is locked but code works fine if device is unlocked?

    Vivek Singh
  • Hello Vivek,

    Once the device is locked, I am not able to connect to the device.

    The code run fine whether or not the the device is locked or unlocked.

    I can reprogram the device using C2Prog.exe using the key that I used to lock the device.

    Stephen

  • Hello,

    Still waiting for a solution for this issue.

    Thanks,
    Stephen
  • Steven,

    Have you tried SCI-A boot to see if that enables you to connect to CCS ?

    Vivek Singh
  • Thanks for the reply.

    I believe I was able to connect using SCI-A boot; however, I want to be able to debug the code I downloaded to flash and I am not able to connect in jump to flash boot mode.

    Stephen
  • Boot ROM is not in secure memory. That may be the reason I am able to connect to boot room code and not to secure flash.
  • After connecting to the target in boot to SCIA boot mode I was able to view the secure flash application code in the assembly window.

    What is interesting is that I connected with the incorrect Password. That shouldn't be possible, should it?

    Stephen
  • Maybe, to solve this issue, you could give me a simple project with all the relevant Target configuration that works that I can use to test on my target.

    Plus I would need detailed steps you performed to connect to the target.

    Stephen
  • You can not connect to device when code is running from secure flash or secure RAM. You need to connect when CPU is executing the BOOT CODE that is why recommendation is to use Wait-In Reset but look like with XDS100v2 emulator it's not working hence I suggested SCI-A BOOT. Even tough you are connected to CCS, you should not be able to see content in secure memories unless you UNLOCK the CSM with correct password. Please double check on that.
  • Strange... C2Prog.exe doesn't care if I enter an incorrect password in the program configuration window. It will still flash the chip. I double verified I had the correct path to the file.

    should it should it work that way?

    Stephen
  • Ok... According to C2Prog's user guide, an all 0xFFFF key is a special condition:

         "If the key felds are lef at FFFF, C2Prog will atempt to unlock a locked MCU by using the keys

          embedded in the hex fle at the CSM locatons. Note that contrary to the other felds..."

    So, disregard my email about C2Prog allowing an incorrect key to unlock the flash.

    Stephen

  • Hello Vivek,

    Could you please explain to me what happens when I launch a specific target configuration from View->Target Configurations.

    The Target Configuration file that I am launching and that allows me to view the secure flash contains the code security password as shown below (by right clicking on Target Configuration item in View->Target Configuration and select properties).

    As  you can see, the password is all 0xFFFFs; However, the password for the program is diferent as shown in the password.asm file below.   I verified the password.asm file was correct by using it with CProg.exe to download the program to the target.

    Stephen

    ***********************************************************************
    * File: Passwords.asm
    * Devices: TMS320F2833x
    * Author: David M. Alter, Texas Instruments Inc.
    * History:
    *   12/18/07 - original (D. Alter)
    * Notes:
    *  1) The section "passwords" contains the actual CSM passwords that get
    *     linked to the CSM password locations in flash.  The user must know
    *     what these passwords are in order to unlock the CSM.
    *  2) Link the section "passwords" to the memory PASSWORDS on page 0.
    *  3) It is recommended that all passwords be left as 0xFFFF during code
    *     development.  Passwords of 0xFFFF are dummy passwords, and do not
    *     lock the code security module (Dummy reads of CSM PWL registers
    *     will unlock the CSM).  When code development is complete, the user
    *     can modify the passwords to activate the code security module.
    *  4) The section "csm_rsvd" is required when using code security.
    *     Failure to program addresses 0x33FF80 through 0x33FFF5 in the
    *     flash to all 0x0000 can compromise security.  This is documented
    *     in the F2833x datasheet, SPRS439.
    *  5) Link the section "csm_rsvd" to the memory CSM_RSVD on page 0.
    ***********************************************************************
    
    	.sect "csmpasswds"
    
    	.int	0xAAFF		;PWL0 (LSW of 128-bit password)
    	.int	0xFFFF		;PWL1
    	.int	0xFFFF		;PWL2
    	.int	0xFFFF		;PWL3
    	.int	0xFFFF		;PWL4
    	.int	0xFFFF		;PWL5
    	.int	0xFFFF		;PWL6
    	.int	0xFFFF		;PWL7 (MSW of 128-bit password)
    	
    ***********************************************************************
    
    	.sect "csm_rsvd"
    	.loop (33FFF5h - 33FF80h + 1)
    		.int 0x0000
    	.endloop
    
    ***********************************************************************
    
    	.end
    ; end of file Passwords.asm
    

  • Steven,

    Password values in asm file (assuming that is what you are programming) and in flash setting window are not same so it should not unlock the device.

    Can you check if the Unlock_CSM() function in Gel file has been modified to have correct password value to unlock the device?
  • Hi Steven,

    As  you can see, the password is all 0xFFFFs; However, the password for the program is diferent as shown in the password.asm file below.   I verified the password.asm file was correct by using it with CProg.exe to download the program to the target.

    The password shown in "Flash Setting" GUI are not populated by tool but provided by USER. This is input to GUI. Tool uses these values to UNLOCK the device to perform the flash operation (program/erase).

    Not sure if this answers your question though. If not, please provide more detail about your question and I'll try to answer further.

    Vivek Singh

  • Ok..that is why. I had changed password in the Unlock_CSM() function in the gel file some time ago.

    So, the Unlock_CSM() function is ran everytime I try to launch a target configuration?

    From the F28335.gel file, I noticed that OnReset() is the only function that calls Unlock_CSM(), so I am assuming Debug->Reset CPU reset is called every time a target configuration is launched. Is that correct?

    According to processors.wiki.ti.com/.../GEL, OnTargetConnect() is called when the debugger connects to the target. That function calls GEL_Reset(), which I am assuming calls OnReset(). Is that correct?

    Stephen
  • Hi,

    So, the Unlock_CSM() function is ran everytime I try to launch a target configuration?

    Correct.

    From the F28335.gel file, I noticed that OnReset() is the only function that calls Unlock_CSM(), so I am assuming Debug->Reset CPU reset is called every time a target configuration is launched. Is that correct?

    Correct

    According to processors.wiki.ti.com/.../GEL, OnTargetConnect() is called when the debugger connects to the target. That function calls GEL_Reset(), which I am assuming calls OnReset(). Is that correct?

    Correct.

    Vivek Singh

  • Would you have any idea why "Wait-In-Reset emulation mode" doesn't work?
  • Steven,

    I have not used this mode with XDS100v2 emulator but I know that not all emulator supports this. Instead of using emulator setting, pull this pins to correct value on board (if possible) and see if that works.

    Vivek Singh
  • Hello Vivek,

    Rafael said it worked for him.

    He tested it on the F28335 eZdsp Board, and from his video, I can see he's using a XDS100v2 Debug probe.

    Therefore, unless something else is different that I don't know about, I think it should work for my configuration.

    Stephen
  • After launching the target, try resetting the device (toggle XRSn or power cycle the board) and then connect to CCS. See if that works.

    Vivek Singh

  • The debugger wants to also connect to the target when I launch the debugger using the Target Configuration file.

    How can I get it to only launch and not connect?

    Stephen
  • Any information on how to set up the Target Configuration file to only launch the debugger?

    I thought I had it previously working that way, but it's not working that way now.

    Stephen
  • How are you launching the target? You need to right click on target configuration file and then launch it instead of clicking on launch icon.
  • Ok, it's launching without connecting now. I thought I did that yesterday.

    >>After launching the target, try resetting the device (toggle XRSn or power cycle the board) and then connect to CCS. See if that works.

    I tried that a couple of times and it doesn't connect.

    Stephen
  • Stephen,

    Were you ever able to properly connect to your target?

    Regards,
    Rafael
  • I wasn't able to connect to the target when the target is in Jump to Flash boot mode. However, I was able to connect when the target is in SCI-A boot mode. I would rather connect in Jump to Flash boot mode so I can debug the target.
  • Stephen/Desouza,

    If passwords are programmed then one can not connect to device with Flash BOOT setting because ECSL get trigger as soon as code execution jumps to Flash and CCS try to halt. You need to use other BOOT mode to avoid code execution from Flash hence could connect to CCS.

    Regards,
    Vivek Singh
  • I am sorry to hear that; this whole thing worked for me with the board I have here, but I am not an expert on the device itself to have a proper clue on what may be exactly happening on the different boot modes - I wonder if somehow the codes we are loading are responsible for the behavioral differences.

    My next step would be to scope the EMUn pins and see at what point during the initial connection they are being asserted, but apart from that I really don't have much more ideas.