• State TI Thinks Resolved
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 101 subscribers
  • Views 176 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

AM6422: OTP KeyWriter: what’s the real difference w or w/o wp option for SMPK/SMEK program? Here wp option is: "-s-wp --smek-wp"

Sam Lin
Prodigy 60 points
Part Number: AM6422

Problem description:

a. When program SMPK/SMEK without wp option, it can program successfully as below M3 log:

* SMPKH, SMEK:
Programmed 11/11 rows successfully
Programmed 2/2 rows successfully
Programmed 11/11 rows successfully
Programmed 2/2 rows successfully
Programmed 11/11 rows successfully
Programmed 2/2 rows successfully

b. When program SMPK/SMEK with wp option, it can program successfully as below M3 log:

* SMPKH, SMEK:
WP: bl: 1, r: 30, prot: 4
WP: bl: 1, r: 31, prot: 4
WP: bl: 1, r: 32, prot: 4

…

WP: bl: 1, r: 62, prot: 4
WP: bl: 1, r: 63, prot: 4
WP: bl: 1, r: 64, prot: 4
WP: bl: 1, r: 65, prot: 4

May I know what is the real difference w or w/o “-s-wp --smek-wp”? IMO, even without this option, after key programming to the eFuse successfully, the key should be already in the protected state, you can’t change it anymore.

  • 0
    TI__Mastermind 25971 points

    Hi Sam,

    The Write Protect is used to prevent further writes to the corresponding fields. If used, this can prevent accidental writes in multi-pass programming of the OTP.

    After the conversion, the keys are protected.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    Thanks for your reply.

    I'm still confused by the DMSC(M3) output in test.

    Here is my test steps:

    1. We generated a set of SMPKH/SMEK and programmed them into SMPKH/SMEK fields without WP option, and the DMSC log was as below:

    * BMPKH, BMEK:
    BMPKH extension disabled
    BMEK extension disabled

    * SMPKH, SMEK:
    Programmed 11/11 rows successfully
    Programmed 2/2 rows successfully
    Programmed 11/11 rows successfully
    Programmed 2/2 rows successfully
    Programmed 11/11 rows successfully
    Programmed 2/2 rows successfully

    * KEYCNT:
    [u32] keycnt: 0x0
    KEY CNT extension disabled
    [u32] keycnt: 0x0

    No doubt, the programming is sucessful.

    2. We programmed the device again with the same KeyWriter image on the same device without WP option, but the DMSC log shew nothing:

    * BMPKH, BMEK:
    BMPKH extension disabled
    BMEK extension disabled

    * SMPKH, SMEK:

    * KEYCNT:
    [u32] keycnt: 0x0
    KEY CNT extension disabled
    [u32] keycnt: 0x0

    Could you please double confirm if the output is expected and by design? Did DMSC program SMPKH/SMEK again really or just ignore the request?

    3. We generaged a new KeyWriter image with the same SMPKH/SMEK keys as same as the step 1 & 2, but programmed them with WP option:


    * BMPKH, BMEK:
    BMPKH extension disabled
    BMEK extension disabled

    * SMPKH, SMEK:
    WP: bl: 1, r: 30, prot: 4
    WP: bl: 1, r: 31, prot: 4
    WP: bl: 1, r: 32, prot: 4
    WP: bl: 1, r: 33, prot: 4
    WP: bl: 1, r: 34, prot: 4
    WP: bl: 1, r: 35, prot: 4

    ...

    The out  log looks very different from the step 1. We have no idea about what the meaning of the tags "bl", "r", "prot" and their values, could you please have any comments for the output? Other, please help confirm if this opertion has overwrote the keys that's programmed in step1 and step 2.

    4. Repeated step3, and we got the output as below:


    * BMPKH, BMEK:
    BMPKH extension disabled
    BMEK extension disabled

    * SMPKH, SMEK:
    SMPKH is WP, can't program
    WP: bl: 1, r: 30, prot: 4
    WP: bl: 1, r: 31, prot: 4
    WP: bl: 1, r: 32, prot: 4
    WP: bl: 1, r: 33, prot: 4

    ...

    The result was a clear failure and the keys was protected as you commented in previous message.

    After the above steps, I cannot determine which keys are programmed in the SMPKH/SMEK field now as we cannot read these keys back to double confirm. Could you pleaes help check this?

    Thanks.

    Sam Lin

  • 0 in reply to Sam Lin
    TI__Mastermind 25971 points

    Hi Sam,

    Let's start with blank OTP meaning all bits are 0. Then,

    => If X (SMPK, SMEK, MSV, or anything) is programmed without WP, then on re-programming the X:

    • With same value: The TIFS skips the re-programming but return Success.
    • With different value: The TIFS only re-programs if it does not result in a bit flip from 1 -> 0 otherwise return Failure.

    => If X (SMPK, SMEK, MSV, or anything) is programmed with WP, then on re-programming the X:

    • With same/different value: The TIFS returns Failure.

    So, your observations are expected and correct.

    -------------

    Sam Lin said:
    After the above steps, I cannot determine which keys are programmed in the SMPKH/SMEK field now as we cannot read these keys back to double confirm. Could you pleaes help check this?

    I believe you were generating the certificate with the same SMPK/SMEK every time. So, those are the keys that are programmed. You should not lose these keys at any cost otherwise there is no way to get them back.

    Regards,

    Prashant