• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 1578 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28033: Error connecting to the target: Device may be operating in low-power mode.

Howard Zou
Genius 12365 points
Part Number: TMS320F28033

Hi,

my customer is using F28033 for mass production.

They are flashing their device with the same software. But they will face below problem in some of the device(about 10%).

By clicking OK, the problem repeat.

And by pull GPIO34 low to set in wait mode, we are able to connect target, erase the flash and program the correct software. And then pull GPIO34 high, we are still able to program the software.

What may be the reason for such issue?

  • 0
    TI__Guru* 80290 points

    Howard,

    We typically recommend customers place the device in wait boot mode to avoid any code from executing until the emulation connection can be established.  The above message is typically due to the Code Security Module (CSM) being activated which will not allow the JTAG connection to complete.  This can happen if the MCU is executing code from a CSM protected region if the device is not unlocked.

    Can you comment on the boot mode customer typically has set, and if this occurs on fresh devices from the factory(all devices come from TI erased) or on previously programmed devices?

    Best,
    Matthew

  • 0 in reply to MatthewPate
    TI__Genius 12365 points

    This happens on fresh devices. 

    Typical boot mode is boot to flash.

    The software we programmed into the device doesn't program the password, CSM are all 0xffff.

  • 0 in reply to Howard Zou
    TI__Guru* 80290 points

    Howard,

    Let me ask a few other inside the team for additional comment.  When we see some population show this kind of behavior, in my experience it means we are relying on the default state of a pin(and it weak internal pull) or a register that is not gated by reset.  There should be an explanation of how this could happen, even if wait boot mode is the answer.  I'll reply back tomm on this.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Genius 12365 points

    Matt,

    thank you.

    We've also doubt about CSM before, we've doubt that the device may be locked by reset during programming due to some unknowing reason.

    But if the device is locked with random password due to reset during programming, we are not able to unlock and program the device even in wait mode.

  • 0 in reply to Howard Zou
    TI__Guru* 80290 points

    Howard,

    I wasn't able to resolve this today, I'll need another day to research a bit more.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Guru* 80290 points

    Howard,

    Here are the scenarios I can come up with:

    Boot mode is flash boot:

    1)Device is in erased state/shipped new from TI:

    In this case the device will attempt to jump to the flash entry point.  Since it is erased it will attempt to execute the op-code 0xFFFF.  This is not a valid op-code, and will translate as and an illegal instruction (ITRAP1).  This will then jump to the TRAP ISR back in BROM.  The behavior here is to enabled the WD and loop forever.  Once the WD times out it will initiate a XRSn and boot process will begin again.  

    If an emulation connnection is attempted at this point it has a very high chance of initial connection since BROM is unsecure(recall that even though device has no password, a read of the CSM locations must still be performed to fully unlock the device). 

    However, there is a persistent issue; in that if the customer doesn't halt the device(by connecting/halting) eventually the code will re-fetch the flash entry point due to the Watchdog reset.  When it does this it will execute the single instruction from flash, which is still secure and terminate the JTAG connection.

    2)Device is already programmed:


    Assuming customer does not have CSM password programmed into the device, as long as they have unlocked the device by the CSM read in their flash code; the debug connection should be OK, since no matter the memory the device is executing from will be un-secure and not trip the CSM JTAG disconnect logic.

    There is still a small window where code has begun execution from flash, but before customer unlocks the device; that will cause an issue with the JTAG connection, since there will be memory access to a secure region.  I would think this is unlikely if customer had waited for enough time for the device to be past this portion of the code.

    3)Wait Boot Mode:

    This solves any of the potential issues above(including if the customer has programmed a password and not unlocked the device).  The WD is enabled in this condition; but code is always executing out of unsecure BROM and therefore any JTAG connection should work.  Note that even in this case, after the JTAG connection is established if customer attempts to read/execute out of a secure memory before unlocking the device it will still cause emulation disconnect.  I believe that there is default action of the GEL file in CCS to do a dummy read of the CSM on connection to prevent this if there is no password in the CSM.  So it is likely this will not be an issue for the customer.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Genius 12365 points

    Matt,

    thanks.

    So according to your answer, the error

    "Error connecting to the target: Device may be operating in low-power mode"

    is still related to the reason that the device is locked, right?

    Then why the error is not reporting "the device is locked"?

  • 0 in reply to Howard Zou
    TI__Guru* 80290 points

    Howard,

    Yes I agree with your statement.  I believe the issue here is the action if the code executes from a secure region; and that is for the device to terminate the JTAG connection.  CCS interprets this as the device being in a low power state since it cannot establish the connection.

    This is different than trying to program the device w/o the proper password.  In this scenario the device is not running from secure memory with the CSM locked, so the JTAG connection is not broken, but the device can return a message that the flash is locked and can't be programmed.

    Best,

    Matthew