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.

TMS320F28335: target device locked: c28xx: gel output: adc calibration not complete, check if device is unlocked and recalibrate

Part Number: TMS320F28335
Other Parts Discussed in Thread: C2000WARE, UNIFLASH

Hello,

I was flash programming the F28335 and I got this message:

c28xx: gel output: adc calibration not complete, check if device is unlocked and recalibrate

The memory at the password location reads 0x0000 so I guess the device is locked.

It is my understanding that the device gets locked during flash programming if there is an interruption of the power supply during the erasing operation, but the device was powered by an external 5 V power supply as suggested by the technical manual....so why did it get locked?

In general, why does the c2000 gets locked by design? is there a way to unlock it? It is quite frustrating to buy a new part every time..

thanks

Francesco

  • The memory at the password location reads 0x0000 so I guess the device is locked.

    If you read 0x0000 for the PWD locations, the device is indeed locked. Did your application code have passwords in them?

    It is my understanding that the device gets locked during flash programming if there is an interruption of the power supply during the erasing operation

    Your understanding is correct. Note that even current starvation during the Erase/Program operation could corrupt the flash. The external power-supply you are using should not only be able to supply the needed current but it should also be able to respond to instantaneous demands without any droop in voltage. Good power-supply decoupling on your board should mitigate this problem.

    why does the c2000 gets locked by design?

    It does not get locked by "design". Flash corruption only happens when there is a blackout/brownout during programming, unless of course the device was defective to start with. This should be rare since all devices are tested thoroughly (including flash) before they are shipped out of the factory.

    is there a way to unlock it?

    Not if the passwords are unknown. 

    The following posts may provide some insights that could be useful for you:

    https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1104019/tms320f28335-device-locked-error-of-gel-file

    https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1104107/tms320c2801-not-ble-to-program-the-device-device-got-locked-after-programming

    https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1066712/tms320f28335-device-is-locked-or-not-connected

    https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1040156/sm320f28335-ep-new-device-seems-locked

    https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1085949/tms320f28335-corruption-flash-memory-when-it-is-erased/4022033#4022033

  • Hello Hareesh,

    thanks for the reply. I have few more questions:

    1)   How can I check in CCS that I am not writing on the password location?

    2)  Apart from the voltage drop during flash erasing and programming, is there another reason for flash corruption (assuming that the program does not 

         write on the password location). Is there a good practice to follow for flash programming (ex: can I debug the code with breakpoints between erase and write operations)? 

    3) Regarding the power supply, I have found 2 types of AC/DC unit:

         a) +5V and max 3A output, voltage accuracy of 95%, noise ripple of 50 mVpp max and response time of 0.4 ms (load from 75% to 100%).

         b) +5V and max 3A output, voltage accuracy 96.5%, noise ripple of 80 mVpp max and response time of 1 ms (load from 10% to 100%)

         In your opinion, which one is more suitable for flash progamming of a F28335?

    thanks

    Francesco

  • 1)   How can I check in CCS that I am not writing on the password location?

    You need to check your project to ascertain if you have a .asm file containing passwords. Take a look at DSP2833x_CSMPasswords.asm in C:\ti\c2000\C2000Ware_4_00_00_00\device_support\f2833x\common\source directory, for example. If you don’t include a similar file in your project, nothing will get written in PWL and the device would remain unlocked. 

    The .map file will tell you if something is being written in the password locations, but it cannot tell you the content. If 0xFFFF is written in the PWL, then your device remains unsecure. If anything else is written, the device would be secured.

    2)  Apart from the voltage drop during flash erasing and programming, is there another reason for flash corruption

    If the power-supply is robust and the erase/program operation is not interrupted in any way, flash corruption should not happen. Of course, there is a possibility that the flash circuitry could be defective in the device. But as mentioned before, the probability is fairly low. This is a fairly old device and technology is mature.

    can I debug the code with breakpoints between erase and write operations)? 

    This is not necessary. 

     In your opinion, which one is more suitable for flash progamming of a F28335?

    Both units are suitable. 

    What is the history of the device? Is this a fresh device that you tried programming for the first time or did you try reprogramming an old device? Also, what method did you use to program? In how many devices did you see this problem?

  • Hello Hareesh,

    I am including the file DSP2833x_CSMPasswords.asm in the TI  folder C:\ti\c2000\.........\source as linked resource of the project. 

    Regarding the .map file, below I have highlighted in yellow parts of the file where the pwl location is concerned....do you see any clear issue?

         What is the history of the device? Is this a fresh device that you tried programming for the first time or did you try reprogramming an old device? Also,         what method did you use to program? In how many devices did you see this problem?

    I have locked 2 devices, one which I programmed several times (around 2-3 months) and another one which was new (it got locked after few flash programming tests). For the programming, I am using the Flash API library and I am programming individual bytes with the function EEPROM_ProgramSingleByte at a writing frequency of 10 kHz. 

    thanks

    Francesco

    MEMORY CONFIGURATION

    name origin length used unused attr fill
    ---------------------- -------- --------- -------- -------- ---- --------
    PAGE 0:
    BEGIN 00000000 00000002 00000002 00000000 RWIX
    ........................

    ZONE7A 00200000 0000fc00 00000000 0000fc00 RWIX
    FLASHH 00300000 00008000 00000000 00008000 RWIX
    FLASHG 00308000 00008000 00000000 00008000 RWIX
    FLASHF 00310000 00008000 00000000 00008000 RWIX
    FLASHE 00318000 00008000 00000000 00008000 RWIX
    FLASHD 00320000 00008000 00000000 00008000 RWIX
    FLASHC 00328000 00008000 00000000 00008000 RWIX
    FLASHA 00338000 00007f80 00000609 00007977 RWIX
    CSM_RSVD 0033ff80 00000076 00000000 00000076 RWIX
    CSM_PWL 0033fff8 00000008 00000000 00000008 RWIX
    ADC_CAL 00380080 00000009 00000007 00000002 RWIX
    IQTABLES 003fe000 00000b50 00000000 00000b50 RWIX
    IQTABLES2 003feb50 0000008c 00000000 0000008c RWIX
    FPUTABLES 003febdc 000006a0 00000000 000006a0 RWIX
    BOOTROM 003ff27c 00000d44 00000000 00000d44 RWIX
    RESET 003fffc0 00000002 00000000 00000002 RWIX

    PAGE 1:
    BOOT_RSVD 00000002 0000004e 00000000 0000004e RWIX
    RAMM1 00000400 00000400 00000380 00000080 RWIX
    DEV_EMU 00000880 00000180 000000d0 000000b0 RWIX
    FLASH_REGS 00000a80 00000060 00000008 00000058 RWIX
    CSM 00000ae0 00000010 00000010 00000000 RWIX
    ADC_MIRROR 00000b00 00000010 00000010 00000000 RWIX

    ...............


    FLASHB 00330000 00008000 00000000 00008000 RWIX
    CSM_PWL 0033fff8 00000008 00000008 00000000 RWIX
    PARTID 00380090 00000001 00000001 00000000 RWIX


    SECTION ALLOCATION MAP

    output attributes/
    section page origin length input sections
    -------- ---- ---------- ---------- ----------------
    codestart
    * 0 00000000 00000002
    00000000 00000002 DSP2833x_CodeStartBranch.obj (codestart)

    .ebss 0 0000a000 000000cb UNINITIALIZED
    0000a000 00000040 F2833x_EEPROM.obj (.ebss:_Write_Buffer)
    0000a040 0000001c F2833x_EEPROM.obj (.ebss:_FLASH_pointer)
    0000a05c 0000001a FFT_radix2_iter.obj (.ebss)

    ...............

    ramfuncs 0 003384ff 0000010a RUN ADDR = 000084ff
    003384ff 000000eb F2833x_EEPROM.obj (ramfuncs)
    003385ea 0000001b DSP2833x_SysCtrl.obj (ramfuncs)
    00338605 00000004 DSP2833x_usDelay.obj (ramfuncs)

    DevEmuRegsFile
    * 1 00000880 000000d0 UNINITIALIZED
    00000880 000000d0 DSP2833x_GlobalVariableDefs.obj (DevEmuRegsFile)

    FlashRegsFile
    * 1 00000a80 00000008 UNINITIALIZED
    00000a80 00000008 DSP2833x_GlobalVariableDefs.obj (FlashRegsFile)

    CsmRegsFile
    * 1 00000ae0 00000010 UNINITIALIZED
    00000ae0 00000010 DSP2833x_GlobalVariableDefs.obj (CsmRegsFile)

    ........................

    CsmPwlFile
    * 1 0033fff8 00000008 UNINITIALIZED
    0033fff8 00000008 DSP2833x_GlobalVariableDefs.obj (CsmPwlFile)

    PartIdRegsFile
    * 1 00380090 00000001 UNINITIALIZED
    00380090 00000001 DSP2833x_GlobalVariableDefs.obj (PartIdRegsFile)

    .text 0 00009000 00000a74
    00009000 00000316 DSP2833x_DefaultIsr.obj (.text:retain)
    00009316 00000107 F2833x_EEPROM.obj (.text)
    0000941d 000000f8 DSP2833x_SysCtrl.obj (.text)
    00009515 000000ee Example_2833xAdcSoc_flash.obj (.text)
    00009603 000000ca rts2800_fpu32.lib : e_log2f.c.obj (.text)

    ..............................

    GLOBAL DATA SYMBOLS: SORTED BY DATA PAGE

    address data page name
    -------- ---------------- ----
    00000400 10 (00000400) __stack

    ..............................

    0000a0b6 282 (0000a080) _Sector_End
    0000a0b8 282 (0000a080) _FlashStatus
    0000a0bc 282 (0000a080) _ProgStatus

    0000a0c0 283 (0000a0c0) _Read_Buffer
    0000a0c4 283 (0000a0c0) __lock
    0000a0c6 283 (0000a0c0) __unlock
    0000a0c8 283 (0000a0c0) _Bank_Status
    0000a0c9 283 (0000a0c0) _Page_Status
    0000a0ca 283 (0000a0c0) _errno

    0000b000 2c0 (0000b000) _PieVectTableInit

    0033fff8 cfff (0033ffc0) _CsmPwl

    00380090 e002 (00380080) _PartIdRegs

  • I am including the file DSP2833x_CSMPasswords.asm in the TI  folder C:\ti\c2000\.........\source as linked resource of the project. 

    I presume you have not edited the default file that is supplied along with C2000ware. The default file contains 0xFFFF for passwords which will not lock the device.

    Regarding the .map file, below I have highlighted in yellow parts of the file where the pwl location is concerned....do you see any clear issue?

    As I said before, the .map file will only tell you "something" is getting loaded in that memory space but does not tell you anything about the content. One way to look at the content is to convert your COFF file (.out file) to a hex file and examining that file on a ASCII editor. The password locations are located at the very end of the flash range, making it easy. This can tell you if anything other than 0xFFFF is written to the password locations. Unlikely, but you are trying to debug..

    I am using the Flash API library and I am programming individual bytes

    OK. I was under the impression that you were using the CCS flash plug-in or UniFlash. When you are programming at the word level,  probability of something going wrong becomes higher. You may benefit from https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/757585/faq-f05-flash-frequently-asked-questions