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/TMS320F28069M: Issues connecting to target with CSM and Password Match Flow.

Part Number: TMS320F28069M

Tool/software: Code Composer Studio

I am testing out the CSM on a launchpadXL board. My intention was to start with the CSM enabled but with the full password match flow, then only half the password match flow and then none, but I got stuck on the first part.

I am able to attach to the target/program it if I have selected the "Emuation Boot" with the bootmode switches of the launchpad. I would like to be able to attach/program the device when it is running from Flash as well (GetMode bootmode), but this doesn't work at the moment. One of the first things my program does, is run the whole Password Match Flow. I thought this would allow me to connect to the target as soon as it has been completed (which would be almost instantly after turning on). However this is not the case, as instead I get this error: 

Error connecting to the target:
(Error -1135 @ 0x0)
The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation.
(Emulation package 8.0.903.4).

The code for the Password Match Flow is taken directly from the TRM:

volatile int *CSM = (volatile int *)0x000AE0; //CSM register file
volatile int *PWL = (volatile int *)0x003F7FF8; //Password location
volatile int tmp;
int I;
// Read the 128-bits of the password locations (PWL)
// in flash at address 0x3F 7FF8 - 0x3F 7FFF
// If the device is secure, then the values read will
// not actually be loaded into the temp variable, so
// this is called a dummy read.
for (I=0; I<8; I++) tmp = *PWL++;
// If the password locations (PWL) are all = ones (0xFFFF),
// then the device will now be unsecure. If the password
// is not all ones (0xFFFF), then the code below is required
// to unsecure the CSM.
// Write the 128-bit password to the KEY registers
// If this password matches that stored in the
// PWL then the CSM will become unsecure. If it does not
// match, then the device will remain secure.
// An example password of:
// 0x11112222333344445555666677778888 is used.
EALLOW;
*CSM++ = 0x1111; // Register KEY0 at 0xAE0
*CSM++ = 0x2222; // Register KEY1 at 0xAE1
*CSM++ = 0x3333; // Register KEY2 at 0xAE2
*CSM++ = 0x4444; // Register KEY3 at 0xAE3
*CSM++ = 0x5555; // Register KEY4 at 0xAE4
*CSM++ = 0x6666; // Register KEY5 at 0xAE5
*CSM++ = 0x7777; // Register KEY6 at 0xAE6
*CSM++ = 0x8888; // Register KEY7 at 0xAE7
EDIS;

These are the contents of the memory browser window pointed at password memory locations directly after loading the program:

0x003F7FF8 PWL_PWL0
0x003F7FF8 0x1111
0x003F7FF9 PWL_PWL1
0x003F7FF9 0x2222
0x003F7FFA PWL_PWL2
0x003F7FFA 0x3333
0x003F7FFB PWL_PWL3
0x003F7FFB 0x4444
0x003F7FFC PWL_PWL4
0x003F7FFC 0x5555
0x003F7FFD PWL_PWL5
0x003F7FFD 0x6666
0x003F7FFE PWL_PWL6
0x003F7FFE 0x7777
0x003F7FFF PWL_PWL7
0x003F7FFF 0x8888 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
0x003F8007 0x0000

  • If the device is secured with a password, the ECSL would trip the emulation connection and you will not be able to connect to the device. This is the reason we have the Wait boot mode option. This has been explained in multiple e2e posts. Kindly do a search. 

    One of the first things my program does, is run the whole Password Match Flow.

    Please clarify why your code runs the PMF. If you want the ability to connect to the target, why program the passwords in the first place? Perhaps I am missing something.

  • One thing you need to ascertain is if your code in flash is really getting executed. You could try this idea: Read the SECURE bit in CSMSCR register to determine if the device is secure or unsecure. If it is secure, toggle a GPIO pin. If it is unsecure, toggle another GPIO pin. This way, you can ascertain two things

    1. The bootmode is correctly configured to flash and that the your code in flash is actually getting executed.
    2. You can correctly determine whether the device has been unsecured by PMF.
  • Thanks for your answer Hareesh. I have read other posts related to this issue (with your responses) but they were all slightly different from what I was experiencing.

    I have also tried using the Wait bootmode using the switches on the launchXl but to no avail. This really confuses me, as it seemed the Wait bootmode should just work in this case. This makes me think it's some setting in CCS I'm overlooking.

    The code is not supposed to run the PMF in production. This was for the very first step of my exploration of the CSM. I expected to be able to just connect, after which I would do only half of the PMF (for the ECSL) while testing all the features, with finally settling for the fully secured device.

    I have "verified" that the PMF is run, by flashing the device (the device now has the passwords programmed but is still not secured), stepping up to the first instruction of the PMF code, securing the device by changing the FORCESEC bit using the debugger and then letting the program run. After this point, the debug connection is stopped and I am not able to reconnect.

    I will also try your suggestion of the GPIO pin, as right now I'm just grasping at straws.

  • I have selected the "Emuation Boot" with the bootmode switches of the launchpad

    I see that there is a switch to connect the -TRST signal to the MCU, but you really don’t "select" emulation mode with the switches. This mode is selected by virtue of the -TRST signal being driven high by debug probe during CCS connection. 

    I have also tried using the Wait bootmode using the switches on the launchXl but to no avail. This really confuses me, as it seemed the Wait bootmode should just work in this case. This makes me think it's some setting in CCS I'm overlooking.

    You are correct that even if the device is secure, Wait mode should allow CCS to connect to the device, since you are not accessing secure memory (which would trip ECSL) 

    The code is not supposed to run the PMF in production. This was for the very first step of my exploration of the CSM. I expected to be able to just connect, after which I would do only half of the PMF (for the ECSL) while testing all the features, with finally settling for the fully secured device.

    I regret I still don’t understand what you are trying to do. Is your expectation that the PMF would have unsecured the device and keep it "ready" when CCS tries to establish a connection? What do you mean by "half of PMF"? 

    I have "verified" that the PMF is run, by flashing the device (the device now has the passwords programmed but is still not secured), stepping up to the first instruction of the PMF code, securing the device by changing the FORCESEC bit using the debugger and then letting the program run. After this point, the debug connection is stopped and I am not able to reconnect.

    When you secure the device by changing FORCESEC, the very first access to any secure memory (flash, in your case) would trip the ECSL. This is what you are seeing.

  • I am using the launchpadXL to try out the CSM. I.e. I would like to learn how to use it and how it affects my code/debugging environment. That is why I am trying to progressively increase the security, starting from CSM enabled but with PMF. I am however stuck on this first part.

    I expect the PMF to unsecure the device, allowing CCS to connect at any point after doing the PMF, because the ECSL would be disabled as well. By half of the PMF, I mean dummy reading all the password locations, followed by writing only the lower 64-bits (half of the password) to the KEY register. According to "TMS320x2806x Piccolo TRM", this should disable only the ECSL, while leaving the CSM intact.

    Hareesh J said:
    When you secure the device by changing FORCESEC, the very first access to any secure memory (flash, in your case) would trip the ECSL. This is what you are seeing.

    This is indeed what I expected. I also expected to be able to reconnect immediately after disconnecting, since the PMF has been run. When the ECSL trips, is this a one time thing or is my connection somehow affected untill a reset of the target?

  • I managed to get it working the way I expected. As I thought, I think my issue has more to do with my understanding of how the emulator/debugger works instead of the CSM. Could someone confirm that what I did is the correct way to do it/explain why this solution works?

    I verified with an oscilloscope on GPIO pins whether the CSM was on, as per Hareesh's suggestion. I used two pins with different polarity to make sure my code was being executed and not some internal pull-up/down. This confirmed that my code was running as expected, but I still couldn't connect, even though the device wasn't secured. I fixed this by changing the launchpad's bootpins while the target was already turned on. If I switched back from both "Wait" and "GetMode" (after I ran the PMF from Flash) to "Emulation Boot", I could connect again. I also just found out that this is explcitily mentioned in the launchpads User Guide (SPRUI11A):

    The USB debugger cannot connect to the device when S1-Switch 3 is placed in the L

    position because TSRTn is disconnected from the XDS100v2.

    My issue undoubtedly stems from the fact that I'm completely ignorant of how these emulators work/what they do. I will look around myself, but does someone know of a good reference for this?

    Thank you, Hareesh.

  • I fixed this by changing the launchpad's bootpins while the target was already turned on. If I switched back from both "Wait" and "GetMode" (after I ran the PMF from Flash) to "Emulation Boot"

    You don’t "switch to" Emulation boot mode, as I explained in my previous post. The -TRST signal is a critical signal to bring the device under the control of CCS. If the path of that signal is cut from the debug probe ("emulator") to the device, CCS will not be able to establish connection with the device. To summarize, that switch which establishes the path for -TRST must be "on" for CCS to establish connection with the device. Once that switch is "on" (i.e. the debug probe can manipulate the -TRST signal of the device) and -TRST signal is driven high, the other two boot-mode select pins (GPIO34 & GPIO37) become a "don’t care"