• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 31 subscribers
  • Views 243 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.

Original question:

TMS570LC4357: OTP Mutability due to ECC

TMS570LC4357: OTP Questions

Paul Sheppard
Prodigy 130 points

Part Number: TMS570LC4357

Have some questions I can't find the answer to here, in the reference manual or datasheet (which are both VERY light on details!)

So found the example here:

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1275733/faq-tms570lc4357-examples-and-demos-for-hercules-controllers-e-g-tms570x-rm57x-and-rm46x-etc/5045583

In there the code is run from RAM - I guess this because it seems the the OTP actually resides in flash (bank 0 or 1), and you can't write to the same bank you're reading from? Unlike FEE in bank7, where you can execute the writing code from bank 0 or 1.

I understand the first 16 bytes (0xF0000000-0xF000000F) are reserved for AJSM. So must avoid writing here.

One thing I'm most unclear on, is if you can write to the 4Kbyte OTP bank multiple times? So for instance write 8 bytes at 0xF0000010, then at a later time 8 bytes at 0xF0000020?

And can you overwrite something you alread wrote to, to 'clear it'? For example overwrite the 8 bytes written at 0xF0000010 with 0's (so change any 1's to 0's). I suspect though this would mess up the ECC?

Thanks!

  • 0
    Prodigy 130 points

    On a related note, we have the following after a flash operation in the example (it's also in the boot loader code too):

            while( FAPI_CHECK_FSM_READY_BUSY == Fapi_Status_FsmBusy );
        while(FAPI_GET_FSM_STATUS != Fapi_Status_Success);

    Does the 2nd while need to exist?

    Does the first one not wait until the operation is complete, and the 2nd provide the result? Do we really need to continue waiting?

    Basically I would prefer for the operation to fail with an error code, rather than while(1) forever!

  • +1 in reply to Paul Sheppard
    TI__Guru* 77556 points

    Hi Paul,

    Paul Sheppard said:
    One thing I'm most unclear on, is if you can write to the 4Kbyte OTP bank multiple times? So for instance write 8 bytes at 0xF0000010, then at a later time 8 bytes at 0xF0000020?

    Yes, you can do that! 

    You can do multiple writings like 8 bytes and another 8 bytes etc.

    Paul Sheppard said:
    And can you overwrite something you alread wrote to, to 'clear it'? For example overwrite the 8 bytes written at 0xF0000010 with 0's (so change any 1's to 0's).

    You can do this as well; you can do second write on same location and can change some of the 1's which are not written with 0's on first iteration.

    Paul Sheppard said:
    I suspect though this would mess up the ECC?

    I think you are right about this one as well. ECC can be mess-up. I never tested practically, but i think this could happen.

    Paul Sheppard said:

    Does the 2nd while need to exist?

    Does the first one not wait until the operation is complete, and the 2nd provide the result? Do we really need to continue waiting?

    The first one is related to FSM state machine and second one is related to exact operation wise status.

    I think it would be good to keep both whiles for to terminate properly.

    And also, i could see same conditions for all the examples.

    --

    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 130 points

    As ever, many thank Jagadish.

    jagadish gundavarapu said:

    The first one is related to FSM state machine and second one is related to exact operation wise status.

    I think it would be good to keep both whiles for to terminate properly.

    Problem is of course, if something goes wrong you're there forever. Think I'll need to change that. Timeout or workout the which bits mean is done but failed.

  • 0 in reply to Paul Sheppard
    Prodigy 130 points

    Maybe the CSTAT bit can be waited on? 

  • 0 in reply to jagadish gundavarapu
    Prodigy 130 points
    jagadish gundavarapu said:
    You can do this as well; you can do second write on same location and can change some of the 1's which are not written with 0's on first iteration.

    Just been trying this, but I get the INVDAT (invalid data: 0->1 change) bit set. I'm writing all 0's, so the ECC part must be trying to write a 1 to a 0.

    It would seem then that this is a no-go.

  • 0 in reply to Paul Sheppard
    TI__Guru* 77556 points

    Hi Paul,

    Paul Sheppard said:

    Just been trying this, but I get the INVDAT (invalid data: 0->1 change) bit set. I'm writing all 0's, so the ECC part must be trying to write a 1 to a 0.

    It would seem then that this is a no-go.

    I didn't get this, could you please tell me where exactly INVDAT bit set? If you able to provide some screenshots that would be more helpful to understand it.

    --

    Thanks & regards,

    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 130 points

    Attempting to write 0x00000000 to address 0xF000024

    Code is pretty much just the example code mentioned above

  • 0 in reply to Paul Sheppard
    TI__Guru* 77556 points

    Hi Paul,

    I did test at my end, and it is working fine.

    On my first iteration i did this:

    I wrote 0xFEFEFE on location 0xF0000020.

    And then on my second iteration i wrote 0xFCFCFCFC on same location and which replaced my previous data 0xFEFEFE like as shown below:

    So, this means i can write more than one time on OTP section as well.

    Here is my write API code for your reference:

    And i am attaching my complete project for your reference:

    Customer_OTP_Write_Test_RM57x.zip

    Note: This time i tested on RM57x device because currently i don't have LC4357 board with me, the devices are very close to each other except some minor differences. So, please follow same pattern on your device as well.

    --
    Thanks & regards,
    Jagadish.