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.

28069 - Picollo: Unable to flash an out file anymore

Other Parts Discussed in Thread: UNIFLASH, TMS320F28069

Hello,

I have the following error when I try to debug with CCS Version: 5.5.0.00077 :

C28xx: GEL Output:
Device Calibration not complete, check if device is unlocked and recalibrate.C28xx: GEL Output:
Device Calibration not complete, check if device is unlocked and recalibrate.C28xx: Flash Programmer: Device is locked or not connected. Operation cancelled.
C28xx: GEL: File: C:\Users\rafa1007\workspace_v5_5\FLASH_ConTest_1\Debug\TMS320_TMS320F2806x_FLASH_ConTest_1.out: Load failed.

I already flashed and debugged my software without any problem and this issue has appeared without any modification in the CCS configuration or the out file.


Thanks in advance for your support.

Best Regards,

M.Farsi

  • Hi,

    I would like you run a "Test Connection" in Target Configuration window. Do paste the results here. Also, please check the voltage levels on the board and verify whether they're in the tolerable limits. Check for any over-heating components. Let us know what your observations are.

    Regards,

    Gautam

  • Hello Gautam,

    Hereafter the result of the Test connection:

    [Start]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

    [Result]


    -----[Print the board config pathname(s)]------------------------------------

    C:\Users\rafa1007\AppData\Local\.TI\693494126\
        0\0\BrdDat\testBoard.dat

    -----[Print the reset-command software log-file]-----------------------------

    This utility has selected a 100- or 510-class product.
    This utility will load the adapter 'jioserdesusb.dll'.
    The library build date was 'Aug 20 2013'.
    The library build time was '22:56:19'.
    The library package version is '5.1.232.0'.
    The library component version is '35.34.40.0'.
    The controller does not use a programmable FPGA.
    The controller has a version number of '4' (0x00000004).
    The controller has an insertion length of '0' (0x00000000).
    This utility will attempt to reset the controller.
    This utility has successfully reset the controller.

    -----[Print the reset-command hardware log-file]-----------------------------

    The scan-path will be reset by toggling the JTAG TRST signal.
    The controller is the FTDI FT2232 with USB interface.
    The link from controller to target is direct (without cable).
    The software is configured for FTDI FT2232 features.
    The controller cannot monitor the value on the EMU[0] pin.
    The controller cannot monitor the value on the EMU[1] pin.
    The controller cannot control the timing on output pins.
    The controller cannot control the timing on input pins.
    The scan-path link-delay has been set to exactly '0' (0x0000).

    -----[The log-file for the JTAG TCLK output generated from the PLL]----------

    There is no hardware for programming the JTAG TCLK frequency.

    -----[Measure the source and frequency of the final JTAG TCLKR input]--------

    There is no hardware for measuring the JTAG TCLK frequency.

    -----[Perform the standard path-length test on the JTAG IR and DR]-----------

    This path-length test uses blocks of 512 32-bit words.

    The test for the JTAG IR instruction path-length succeeded.
    The JTAG IR instruction path-length is 38 bits.

    The test for the JTAG DR bypass path-length succeeded.
    The JTAG DR bypass path-length is 1 bits.

    -----[Perform the Integrity scan-test on the JTAG IR]------------------------

    This test will use blocks of 512 32-bit words.
    This test will be applied just once.

    Do a test using 0xFFFFFFFF.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.

    The JTAG IR Integrity scan-test has succeeded.

    -----[Perform the Integrity scan-test on the JTAG DR]------------------------

    This test will use blocks of 512 32-bit words.
    This test will be applied just once.

    Do a test using 0xFFFFFFFF.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.

    The JTAG DR Integrity scan-test has succeeded.

    [End]

    Voltage levels are OK.

    For Information, the software flashed previously (when it was working) is doing some flash erasing/swritting operations.

    [EDIT] I just checked this info in the documentation:

    "The 128-bit password (at 0x3F 7FF8 – 0x3F 7FFF) must not be programmed to zeros. Doing
    so would permanently lock the device."
    This writting operation has problably runned during my test. Is there a way to check it ?

    [EDIT]

    Thank you.

    BR,

    Rachid

  • Rachid, then your device seems to be locked (may be permanently)! Here's a last check you can perform:

    Download CCS Uniflash -> Unlock your device using the option available in the software and

    Then try flashing your chip. Let us know what your observations are.

    Regards,

    Gautam

  • Hello Gautam,


    I tried to unlock with CCS UniFlash (TMS320F28069 FalshSettings -> Unlock)
     and and I have the following error:

    [12:12:07] C28xx: GEL Output:
    Device Calibration not complete, check if device is unlocked and recalibrate.
    [12:12:07] C28xx: Starting device unlocking...
    [12:12:07] ERROR >> C28xx: Flash Programmer: Error unlocking flash memory. Device is still locked
    [12:12:07] Flash operation Unlock failed on core Texas Instruments XDS100v2 USB Emulator/C28xx

    I guess this unlock is possible when the passeword has not been overwritten with 0 (as I did unfortunatly). Is there another solution to unlock the flash?

    Regards,

    Rachid

  • Rachid, here's an extract that might help you unlocking the device:

    Well, you've certainly got yourself into a situation!
    
    Is the .hex file a complete image such that it contains the passwords?  If so, then my thinking is this will be the easiest file to deal with since it is ASCII, whereas the .out and .bin are binary files.  I assume this is one of the formats the compiler hex2000 tool produces, such as Intel format, or Motorola-S record, etc.  There is a description of these formats in the C2000 ASM Language Tools User's Guide, SPRU513G.  This will help you parse through the file.
    
    Do you recall if in the source code, you had the passwords in their own named section?  That is how TI examples have it.  Hopefully you do, as that will make things a lot easier.  The passwords are at addresses 0x3F7FF8 - 0x3F7FFF.  If the passwords were in their own named section, that section would appear seperately in the .hex file along with its starting address of 0x3F7FF8, and have a length of 8 16-bit words (or 16 bytes, not sure if the .hex file shows byte or word lengths.  You'll need to look).  You can search the .hex file for 0x3F7FF8 (or various ordered forms for this, such as
    
    00 3F 7F F8
    
    3F 00 F8 7F
    
    7F F8 00 3F
    
    F8 7F 3F 00
    
    You can probably figure out the byte endianess that the section addresses appear in the file.  You need to figure it out anyway for the data, as you need to get the passwords into the correct order assuming you are able to locate them.
    
    This could be a pretty long and tedious process.
    
    I have one other thought, but I cannot guarantee it will not lock up another board.  I recall that after flashing a .out file in CCS, the processor is NOT reset.  If the CSM is unlocked (which it will be during/after flash programming), it will not lock until you reset the device.  So, if you had another board, you could flash the .out file into the device using CCS.  Then, view the flash passwords in a memory location.  DO NOT RESET OR POWER CYCLE the device after flashing it until you see what the passwords are.  Otherwise, you're going to lockup that board too.  You would need to do this very carefully.  My suggestion would be to practice/verify the procedure first using a different .out file for which you know the passwords.  That way if it doesn't work (i.e., the CSM is locked after flash programming with CCS) you can recover the second board and know that you should not try it with the .out for which you don't know the passwords.
    
    Good Luck and let us know how it goes.
    
    Regards,
    
    David
    
    -----------------------------
    David M. Alter
    Senior Member Technical Staff
    Texas Instruments Inc.

    Regards,

    Gautam

  • Gautam,

    Unfortunarly this doesn't help me because I know what CSM passeword has been written at this adress : 0 value which lock the board "permanently". (I checked with a memory map during a test connection that memory has been programmed to zero). But I guess this permanently is not true and there exists a solution. If you can find it, it would be very helpful.

    Thank you in advance.

    Regards,

    Rachid

  • I'm forwarding your query to one of my buddy at TI. Hope you get the info you're seeking for.

    Goodluck & Regards,

    Gautam

  • Hi Rachid,

    If you wrote all 0s as the CSM password, your device will be permanently locked. 

    (btw: if you attempt to read any address of secure memory on a locked device you will read all 0s)


    Thank you,
    Brett