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.

TMS320F280041: DCSM OTP repurposed for user data? (serial number)

Part Number: TMS320F280041

So, the link pointer in the DCSM points to a single 0x10 word region in a 0x200 word area of OTP per zone.  Can we use say most of the DCSM zone 2 region (0x78220-0x783EF, for example) for user data, if we are setting the zone 2 link pointers to all 0s to select the last region, and zero that out (0x783F0-0x783FF)?

In fact, it'd seem to me you could do that with both zones and have user OTP data at 0x78020-0x781EF and 0x78220-0x783EF, program both DCSM zones' link pointers to all 0s to use 0x781F0 and 0x783F0 for DCSM bank information, and zero out 0x783F0-0x783FF to disable zone 2.  Does this sound workable?

Our DCSM configuration is to only use zone 1 and lock everything as secure, no JTAG, etc (not EXE only, not quite brave enough for that one)... we really don't need any other configuration than that.

We use the unique ID at 0x730CC in our calibration database, but the user-facing serial number is a much simpler value (like 418, etc).  We'd like to use an unused OTP region to store this version of the serial number and other information.

This is especially important because CCS has a tendency to completely reset the choice for "Program only necessary sectors" and wipe the entire user flash area.  I assume it's some kind of fallback if it has trouble communicating... we ran into this a lot while developing our bootloader and it didn't really happen before that.  It regularly wipes our serial number, so we're looking for a more permanent location for it.

  • ... also, for clarification...  the Technical Reference on table 3-16 does not show a "00" option, and notes "The user should never program any other values in these fields. Failing any these conditions for a RAM block/Flash sector will make that RAM block/Flash sector inaccessible." ... however, the DCSM.asm code generated by the DCSM security tool creates a section (commented out) that zeroes all of the later DCSM zone areas and says "For code security operation, after development has completed, prior to production, all other zone select block locations should be programmed to 0x0000 for maximum security. "

    Is it safe to program DCSM zone 2's CURRENT linked zones to 00s, if it's not being used?

    It's completely unclear to us what happens if you have DCSM zone 1 and DCSM zone 2 marking the same sector secure.  Do both zones need to be unlocked for it to be used?  ... or will unlocking one of the 2 DCSM zones do it?  Ok, so re-reading the section around table 3-16 seems to be saying that 00s on even an unused zone 2 will be bad.  :) 

    So, one problem with using zone 1's unused OTP blocks would be needing it unlocked before being able to read them.  So... if zone 2 was configured to the last link pointer location, and all GRABRAM/GRABSECT bits set to "10", and unlocked and left unlocked by the user application... could it safely read zone 2's OTP data without creating any risk?

  • Hi Darron,

    So, the link pointer in the DCSM points to a single 0x10 word region in a 0x200 word area of OTP per zone.  Can we use say most of the DCSM zone 2 region (0x78220-0x783EF, for example) for user data, if we are setting the zone 2 link pointers to all 0s to select the last region, and zero that out (0x783F0-0x783FF)?

    No, USER OTP is only for security settings and can not be used for any user data because with security enable, that region can not be read by CPU.

    "The user should never program any other values in these fields. Failing any these conditions for a RAM block/Flash sector will make that RAM block/Flash sector inaccessible."

    That is only for the active zone select block where as the value 0x0 is for non-active zone select blocks.

    Is it safe to program DCSM zone 2's CURRENT linked zones to 00s, if it's not being used?

    Should be ok.

    It's completely unclear to us what happens if you have DCSM zone 1 and DCSM zone 2 marking the same sector secure. 

    That is not allowed. Table "RAM/Flash Status" provides are valid configuration. There is note after this table which says that programming any value other than what mentioned in table will make that memory inaccessible.

    Hope this clarifies all the queries.

    Regards,

    Vivek Singh

  • I updated my reply with a final paragraph.  Is it safe to leave zone 2 unlocked if it does not control any sectors, and use that zone as the user data region?  It would be possible to read that data then, right?  We'd set the link pointer to 0s and only use the last zone, so there'd be no ability to create a new zone definition or change the existing one without making the device unusable.

    If a zone MUST have something to control, we could mark our configuration sector (FLASH sector 15) as controlled by zone 2.  That's marked unsecure currently.

    ... would this disable the CPUSL functionality?  ... if either DCSM zone 1 OR 2 are unlocked, CPUSL will be disabled?   ...  I'm not sure that's a showstopper if that's all, though. No, it appears CPUSL and ECSL will still work when the code is running in the locked DCSM zone 1's secure areas.

  • I think that should work but I need to check and get back to you on this. Please note that setting in these region are for security so these would have different attribute. E.g. execution is not allowed from this region.

    Regards,

    Vivek Singh

  • This does work.  Our application is using this now for storing an OTP serial number.  Thanks!