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.

LAUNCHXL-F280039C: Link Pointer Fig.5-1

Guru 55913 points
Part Number: LAUNCHXL-F280039C
Other Parts Discussed in Thread: SYSCONFIG, UNIFLASH

Tool/software:

Hey group.

Figure 5-1 does not represent the blue highlighted text, states MSB position represents offset address, not LSB. Figure 5-1 is draw backwards to what is written of how a link pointer is made valid. What the table shows is to modify LSB bits 1 to 0 because they all start out as 1's in the OTP.  Fig. 5-1 link pointer bit positions are drawn backwards, LSB to MSB. If the text is wrong, then it needs to be corrected to match Fig.5-1 indicate LSB bits (1) must be changed to (0) in the OTP, not state MSB.

Logically it would make sense to change high order (1) bits in descending order for GEL code to work correctly. The x49c GEL ends up 0x00000000 and targets pointer block offset addresses perfectly. 

The table should represent after the fact of modified link pointers (LP) being they are critical for DCSM peripheral working correctly. Either change all the 0's to 1's and 1's to 0's or fix the text to state LSB in ascending order up to MSB bit positions as to elaborate what is being implied by Fig.5-1 for critical OTP bits being changed.

Seemingly it destroys DCSM LP's bits recognition if the MSB is made (0) before LSB has been first changed, x49c DCSM. Perhaps add the words LSB ascending or MSB descending so the reader knows what, why and how. Frankly it doesn't seem logical to modify bits from LSB to MSB in an existing OTP Dword anyway, unless maybe you are Russian. Perhaps DCSM peripheral reads LP's LSB to MSB? Readers have no idea what or why the figure is backwards to the blue text stated first MSB made (0). Noted x49c DCSM if three link pointers of a zone are not made exact same binary value, the LP1 error flag is raised MSB bit position of the changed bit that is not same as LP1. Once all three LP's are made to match, the LP error flag is dropped.

  • Hi Genatco,

    The table is correct. The text is also correct although the wording may be unclear. The text is saying that the location of the most-significant 0-bit is what determines the zone-select block offset address. You can see this reflected in the table as well.

    I would highly recommend using the SysConfig DCSM GUI for OTP code generation as it will take care of this bit-wise logic for you.

    Thank you,

    Luke

  • You can see this reflected in the table as well.

    Luke, disagree as the MSB in 15-bit link pointers are all 1's except for the last offset address ZSB15. Figure 5-1 shows LSB bit positions were made 0, not MSB bit positions being there are remaining 1's in the MSB positions.

    The idea behind OTP bits is NOT to change accept 1 bit at a time per TRM text about OTP bits, driving fear to make large bit changes. Fig.5-1 shows many bits were changed to 0 in each row thus leaving the MSB bit positions all 1's.

    MSB in the resolved Link Pointers are all 1's, not 0's. The zeros are arbitrary as DCSM peripheral does not recognize leading MSB 0's as valid and permanently locks sectors x49c MCU class. Hopefully x39c DCSM is bit more forgiving. The default OTP link pointers are 0xEFFF. The next logical offset selection should be 0xDFFF, 0xCFFF, 0xBFFF etc. until all bit positions become 0x0000 selecting very last offset address.     

    Actually it is LSB position in string of binary 1's that determine a valid offset address according to Fig.5-1. Another problem seems to be UniFlash does not read the current OTP memory and fill in the memory sections are all blank after XDS110 connects to MCU. Noted on LaunchXL39c there was no launch pad board configured, only XDS110. UniFlash should not allow MSB bit positions to be changed in Link Pointers if they are so critical for DCSM peripheral to accept valid.