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.

TM4C1290NCPDT: Once debug is permanently disabled, can a TIVA be unlocked?

Part Number: TM4C1290NCPDT


Hello,

Paragraph 8.2.3.7, Permanently Disabling Debug, describes the process for locking a processor.  Though described as permanent, paragraph 4.3.4.3 describes a method for "unlocking" a microcontroller. 

Once locked IAW 8.2.3.7, can a processor be unlocked using 4.3.4.3? 

If not, what type of "lock" does 4.3.4.3 reverse?

Thanks!

  • Yes, even though debug has been disabled, the TM4C can be unlocked. However, since the flash memory is totally erased in this process, all information about the application is destroyed. I agree that the terminology is misleading. Debug access to the code has been permanently disabled.
  • Thanks, Bob; that is the behavior we were hoping for.

    Tim
  • In the interest of being "more complete" - while "Debug Access" to (that existing) code has been disabled - there are multiple other means of gaining access to that exact code.

    Should your (unexpressed) agenda include "code security" - the simple "JTAG/SWD Disable" offers far from complete protection...
    Such is a universal weakness of MCUs in this price/class category - not any knock - on this particular vendor...
  • Thanks for the info,cb1_mobile. Can you elaborate? Is there some other protection mechanism I should enable? Locking out JTAG and SWD addressed most of the concerns we could think of.

    This is for an embedded product that is about to be fielded.

    Regards,

    Tim
  • In the past - working at another "giant" Semi Firm - we'd regularly (for sport) access our code via, "Non JTAG/SWD means."     (the ever popular "bootloaders" also, "Speed, Ease & Enhance" the ability to, "Access such code" - by adding (even) further security  vulnerabilities!"

    Keep in mind that the Government's best, "Wall Street Financial Regulators" are NEVER as: "Skilled, Determined, Equipped and Financially Motivated" as those they are (attempting) to regulate!     Exact scenario plays out here - if  myself/others - wanted your code - we'd,  "Have your code" - NO Question!    (Decapping the MCU provides yet another means - there are several)

    If doubtful - request a  "Written Guarantee of such "Security's Effectiveness" - from this or (any) other vendor - producing this cost/class type MCU.      No firm will produce/provide such document - that IS "telling" - is it not?

    You may delay a,  "None too skillful 7th grader" (briefly) - but any (real) hacker simply  "laughs" at  this  (pardon)  "Illusion of Protection..."   (Seriously - can a sub 10 (USD) MCU  "be expected to resist attack" - when (multiple)  Major Retailers,  even Credit Bureaus  - cannot?)

    Having past co-founded - serving as VP Engineering - then taking that small, past, Tech Firm PUBLIC - best advice we received was to:

    • insure the product arrived to market EARLY   (when profit potential is MAX)
    • insure the feature mix is inspired, complete, compelling
    • price attractively
    • be able/ready to "Meet Market Demand" -  especially should your Sales projections be understated

    Each of the (above)  "proves far easier to realize"  - than (real/robust) Security!    ("Illusions" not withstanding.)      (you may note that the "head in the sand" Ostrich (likewise believing "that method" Secure)  - did NOT survive the Lion's attack ... even though - and especially though - the Ostrich had,  "Disabled JTAG!")

    May I note that the "facts & parallel instances" reported herein - earns this posting the desired,  "This Resolved my issue" - even though these "facts" prove "inconvenient!"     Such IS  "Reality..."    (Sometimes BRUTAL!)

  • Here on this forum, I am looking specifically for any other TM4C features which we may have overlooked. Features that people find useful towards this end. Advice such as, "in addition to disabling debug, make sure you do X also, otherwise the internals may still be discovered" would be helpful.