• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 82 subscribers
  • Views 1363 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Device Calibration not complete, check if device is unlocked and recalibrate.

Daniel Rush
Intellectual 585 points
Part Number: TMS320F28069M

Tool/software: Code Composer Studio

Attempting to flash a brand new F28069m which is fresh from the factory, using a XDS110 I have been using a DRV8301HC module, and have been using the built in XDS100 to flash that board, moved to our new board and set up a new target configuration. If I run the "Launch Selected Configuration" it launches into the debug screen and I can right click on the c28x debug probe or the cla debug probe, they connect just fine and show that the processor is set at 0x3FF75B which is in the Bootloader. When I try to run a load or an erase or a cpu reset the console outputs "Device Calibration not complete, check if device is unlocked and recalibrate.". I have no reason to believe the processor is locked as it's brand new. The hardware connection of the JTAG connection appears to be the same as on the example board, even though the processor on the controlcard is not connected to the JTAG. I have read related posts and it seems we don't share any problems with the other posts.

  • 0
    TI__Guru 71835 points

    Daniel,

    Thanks for the detail info; the message from the console is coming from the preloaded GEL file that is attempting to load the device calibration on a load or reset.  This info is stored in the OTP, which is secure, and there are checks in the GEL to make sure the calibration values that are loaded are non 0 (read from a locked CSM).

    Just for some background, during normal boot the calibration functions are called as part of the Boot ROM routines, so this won't be an issue with a device running normally, secure or not.  For debug purposes, since often folks compile there code agnostic of the boot loaders, we wanted to make sure that the ADC was calibrated which is why the GEL is trying to do this.

    Now, back to your issue I think there are 3 possibilities:

    1)The calibration function/values are not in the OTP.  We can rule this out since TI programs these at the factory before shipping a device

    2)The device is locked, and the CSM password needs to be provided.  As you said this is a fresh device from TI, and all devices come from us erased.

    3)From a previous debug there are CSM values being passed(either in the target config or the GEL) that are non 0xFFFF, but since this new device is erased that may also lock the device.

    Let's go with #3, 

    From the target config window, right click on your CCXML file and select properties.  Then navigate to the flash settings (mine is the last one in the list) and check the values for the password.  For a new device they need to be all 0xFFFF.

    If this is correct, switch to the debug perspective and under tools there is a GEL files item, click that and then look inside the GEL file for the Unlock_CSM() function and also make sure that those password values are 0xFFFF.

    If all this is correct, then we need to rule out #1 or #2 above.  Confirm that the CSM passwords at 0x3F7FF8 - 0x3F7FFFF read back 0xFFFF.  If that is true(device is unlocked), then try and read locations 0x3d7c83 after the device is unlocked.  If these are either 0 or 0xFFFF then that is also incorrect, and we can go from there.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Intellectual 585 points

    Thanks for the detailed help here!

    Following the instructions for number 3 here are my results:

    ccxml file:

    GEL File:

    Password locations in Memory Browser:

    And reading 0x3D7C83:

  • 0 in reply to Daniel Rush
    TI__Guru 71835 points
    Daniel,
    Thanks for going through the steps.

    If you are reading the PWL in the memory window and showing 0x0000, it means that the device is(somehow) locked/had a password programmed to it. As I said, all devices coming from TI should be in erased/unlocked state when new.

    Is this part on a TI EVM, like a LaunchPad/control card, or was it shipped as a loose device and then mounted on a PCB locally?

    Just to confirm, when you got the above error, this was the first time you were trying to load code to the device?

    Matt
  • 0 in reply to MatthewPate
    Intellectual 585 points

    It is a device that was mounted on a custom PCB.

  • 0 in reply to Daniel Rush
    TI__Guru 71835 points
    Daniel,
    I know this is not ideal, but do you have another device you could try and see if it is also locked? If possible can you take a picture of the top of the "locked" MCU and attach it to your next post?

    Matt
  • 0 in reply to MatthewPate
    Intellectual 585 points

    We have tried the other boards that we have made, 2 out of 3 of them have this issue haven't tried the third one. Here is that picture:

  • 0 in reply to MatthewPate
    Intellectual 585 points
    Also, to your above question, this was my first time plugging in a debugger, I was only able to connect and not access flash at all. These chips were fresh mounted to our PCBs.
  • 0 in reply to Daniel Rush
    TI__Guru 71835 points
    Daniel,
    I'm checking on something in parallel, waiting on a reply from a colleague.

    In the meantime, if under "Tools" you access "On-chip Flash", can you see if CCS will allow you to perform an Erase option? This will use all the default settings, just to see if we can re-cover.

    Best,
    Matthew
  • 0 in reply to MatthewPate
    Intellectual 585 points
    Yea that's one of the things we tried when we first connected the chip, it came back with the same error message when trying to erase the chip.
  • 0 in reply to Daniel Rush
    Intellectual 585 points
    Turns out that our chip did not have the flash peripheral powered. Jumping that connection fixed our issue, thanks.