• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 1065 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RM48L952: Flashing RM48 OTP ECC bits

Westin Sykes
Expert 1315 points
Part Number: RM48L952
Other Parts Discussed in Thread: HALCOGEN

I am working on flashing the AJSM registers along with the associated ECC bits. What I have found is that I can write the OTP bits assuming I don't use Fapi_AutoEccGeneration. If I do use Fapi_AutoEccGeneration, no errors are returned or aborts thrown, but nothing changes in flash. This may not be specific to the OTP bits, as I have not tried flashing ECC bits using the F021 library to any other flash either.

while( FAPI_CHECK_FSM_READY_BUSY != Fapi_Status_FsmReady );
Fapi_StatusType status = Fapi_setActiveFlashBank(Fapi_FlashBank0);
if(status)
	return status;

while( FAPI_CHECK_FSM_READY_BUSY != Fapi_Status_FsmReady );
status = Fapi_enableBanksForOtpWrite(0x1U);
if(status)
	return status;
while( FAPI_CHECK_FSM_READY_BUSY != Fapi_Status_FsmReady );
status = Fapi_issueProgrammingCommand((uint32_t *)(0xF0000000), key->key, 16, NULL, 0, Fapi_AutoEccGeneration);//TODO: Not sure if autogenerate works.
if(status)
	return status;
while(FAPI_CHECK_FSM_READY_BUSY != Fapi_Status_FsmReady);
status = Fapi_disableBanksForOtpWrite();
while(FAPI_CHECK_FSM_READY_BUSY != Fapi_Status_FsmReady);

  • 0
    TI__Guru 72500 points
    I am actually on holiday this week, and do not have an RM48L952 to check this out on. Did you select a visible unlock code that you know generates ECC that can be programmed into the device? Because the visible unlock code for the RM48L952 has a non-blank ECC (0xEDCO), the value you choose must be one where not only the data bits, but also the 8 ECC bits must be able to be created by programming only 1's to 0's. You can use HALCoGen v4.06.00 (0r later) to generate valid AJSM lock codes for the RM48.
  • 0 in reply to Bob Crosby
    Expert 1315 points

    I was wondering if the issue was related to that, as I noticed that value in the ECC space. This really limits the range of possible keys. Is there any way on this platform to use an arbitrary AJSM key? Is there a way for me to generate a random key, zero out a few bits maybe, and have it work without getting an ECC error?

  • 0 in reply to Westin Sykes
    TI__Guru 72500 points

    It does limit the number of possible keys, but there is still an excessively large number of valid keys with valid ECC values. The easiest solution is to use HALCoGen to generate a valid random key.

  • 0 in reply to Bob Crosby
    Expert 1315 points
    I updated HALCoGen and found that feature. Is there example code anywhere of how it generates the codes which have valid ECC bytes? What I would like to do is have AJSM keys which are calculated from the serial number of a device. Right now that works as long as I don't program the ECC bytes which causes other issues.
  • 0 in reply to Bob Crosby
    Expert 1315 points
    I found your post here with a tool that could be modified to do what I want. Has any progress been made in a better solution than guessing and checking as you mentioned?

    e2e.ti.com/.../505678
  • 0 in reply to Westin Sykes
    TI__Guru 72500 points
    The algorithm is simple. It generates a pseudo random number for the keys (I think it uses the lower timer bits on the PC as the initial seed to make it a truly random number) and then AND's them with the visible unlock code. Then it calculates the ECC bytes for the result. If the calculated ECC bytes can be programmed into the existing ECC bytes, it stops and displays those results. Otherwise it starts over generating then next random number. The loop repeats until it finds a solution.

    You could do something similar using the serial number as some type of seed to srand(). You should not just ignore the ECC. The ECC is always used at power on when the AJSM lock code is read from flash. You will eventually end up with a pattern that decodes to a single bit error. Then the ECC will invert a bit in the pattern from flash, making the unlock by scan code different from what you expected.
  • 0 in reply to Bob Crosby
    Expert 1315 points
    I will do that, then. That is good advice about not ignoring the ECC bits. Thanks for the help on your vacation.