• State Resolved
  • Locked Locked
  • Replies 18 replies
  • Subscribers 83 subscribers
  • Views 6994 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.

TMS320F28075: Uncorrectable ECC Error in DCSM OTP Stops Program's Running

Ricky Zhang
Genius 9520 points
Part Number: TMS320F28075
Other Parts Discussed in Thread: CONTROLSUITE

Hi, Champs,

My customer is using F28075 and their product is going to mass production, but recently they found 5pcs boards can't run the program standalone after loading the flash image (with emulator connected after load, it can fully run).

I supported them on-site debug with emulator connected and found the codes will stuck in BOOT ROM (address: 0x3FE444), where is the interrupt void c1brom_handle_nmi() function to handle FLUNCERR in c1brom_interrupts.c source file under folder C:\ti\controlSUITE\libs\utilities\boot_rom\F2807x\revB\rom_sources\F2837x_bootROM\cpu01-bootROM\source:

if(c1brom_nmi_status & NMI_INT_FLUNCERR) /*check for C28FLUNCERR NMI */

{

c1brom_status |= C1_BOOTROM_GOT_A_FLASH_UNCERR_NMI;

//if debugger connected - give a chance to user to know the scenario

asm(" ESTOP0");

//let NMIWD reset the device

while(1);

}

We then identified that NMIFLG.bit.FLUNCERR=1, ERR_STATUS.bit.UNC_ERR_L=1 and UNC_ERR_ADDR_L=0x78010, which means there's an uncorrectable error occurs in the lower 64-bits of a 128-bit memory-aligned data.

Customer software does write value of 0xFFFE to that location, and we observed the content there, it's exactly 0xFFFE as well, but why ECC detected it as uncorrectable error? And how should we handle it as every time to power on, it can not standalone run but will always stuck in the BOOT ROM.

As customer's software is identical and most of their control boards can work well with the same content in 0x78010, do you think it has anything to do with the silicon? 

Best Regards,

Ricky Zhang

  • 0
    TI__Guru* 87145 points
    Ricky,

    1) Did the customer program ECC when programming the Z1-PSWDLOCK at address 0x78010?
    2) If yes, are they programming it as a part of the coff file or using GUI fields of some programming tool?
    3) Which tool are they using to program the Flash?

    Thanks and regards,
    Vamsi
  • 0
    TI__Guru** 115271 points

    Hi Ricky,

    If customer is programming same program on every device and only few are not working then I am assuming customer is programming the ECC for these location but on some part this did not happen as expected. But still as Vamasi mentioned please confirm the same.

    Also I would suggest to compare the ECC value for this location on a working device and non-working device. You need to connect the working and non-working device to CCS and then unlock the device to view the content and corresponding ECC value.

    Let us know what you find.

    Regards,

    Vivek Singh  

  • 0 in reply to Vamsi Gudivada
    TI__Guru* 87145 points
    Ricky,

    Reason it is working with debugger connected might be because of the gel file. Gel file's OnReset() function disables the ECC-check.

    Thanks and regards,
    Vamsi
  • 0 in reply to Vamsi Gudivada
    TI__Genius 9520 points

    Vamsi,

    Thanks for quick response.

    Vamsi Gudivada said:

     
    1) Did the customer program ECC when programming the Z1-PSWDLOCK at address 0x78010?
    2) If yes, are they programming it as a part of the coff file or using GUI fields of some programming tool?
    3) Which tool are they using to program the Flash?

    Yes, they programmed ECC via their own SCI-based programming tools. I will double check on this tomorrow.

    Actually the real procedure is, they programmed the device with their own tool, and when issue occurred, we connected the target with emulator to re-program and debug, but we keep the GUI in default status. Does this matter much with this issue?

    Best Regards,

    Ricky Zhang

  • 0 in reply to Vivek Singh
    TI__Genius 9520 points

    Vivek,

    This is a good idea and we can do the comparison on two devices.

    How can we calculate the ECC location for a specific flash or OTP address?

    DS provided the address range for DCSM OTP ECC, I think we need the exact address of ECC for location 0x78010.

    Best Regards,

    Ricky Zhang

  • 0 in reply to Vamsi Gudivada
    TI__Genius 9520 points

    Vamsi,

    Fortunately, I disabled OnReset() function within OnTargetConnect() function in the gel file before I connected the debugger, since I want to see where the codes are stuck in BOOT ROM after connection.

    Best Regards,

    Ricky Zhang

  • 0 in reply to Ricky Zhang
    TI__Guru* 87145 points
    Ricky,

    Every 64-bit (aligned) OTP data will correspond to 8 ECC bits in ECC space. Since C28x is 16-bit addressable, each address in ECC space will have two ECC bytes - one for lower 64-bits and one for upper 64-bits of an aligned 128-bit OTP memory address. Now you know how to map a given OTP address to it's corresponding ECC address given the start address of the ECC space.

    For address 0x78010, the corresponding ECC address would be 0x01071002. And you need to check LSB here.

    Thanks and regards,
    Vamsi
  • 0 in reply to Ricky Zhang
    TI__Guru* 87145 points
    Ricky,

    Regarding the tool: I wanted to know if this is reproducible with a TI tool and hence asked. If it is not reproducible when programmed with TI tools, it may be their tool issue. However, you mentioned that the issue does not occur on all the devices. Hence, you need to debug further to know why only those specific devices have the issue - may be they programmed those devices with different version of the tool etc.

    Will be able to understand better once you compare the ECC on the failing vs passing devices.

    Thanks and regards,
    Vamsi
  • 0 in reply to Vamsi Gudivada
    TI__Genius 9520 points

    Vamsi,

    Thanks and understand.

    Unfortunately, I still didn't get feedback from customer and maybe we need to respond tomorrow.

    There're two more questions from customer:

    1. Does ECC have to be enabled for DCSM OTP? To all locations including link pointer?

    2.  They told they use their own memory copy function rather than TI-provided safecopy function in all revision silicon, but there're no problems, does it make sense? Please be noted: a. Silicon prior to Rev. B seems to be fine with that? b. Although customer enabled security, they only use Z1.

    Best Regards,

    Ricky Zhang

  • 0 in reply to Ricky Zhang
    TI__Guru* 87145 points
    Ricky,

    #1. I guess you are asking whether to program ECC for DCSM OTP or not. ECC has to be programmed for DCSM OTP as well except for link-pointer locations.

    #2: I will ask our security expert to review your question #2.

    Thanks and regards,
    Vamsi
  • 0 in reply to Vamsi Gudivada
    TI__Genius 9520 points

    Vamsi,

    Vamsi Gudivada said:

     
    #1. I guess you are asking whether to program ECC for DCSM OTP or not. ECC has to be programmed for DCSM OTP as well except for link-pointer locations. 

    Yes, I understand.

    Vamsi Gudivada said:

     
    #2: I will ask our security expert to review your question #2.

    They didn't use EXEONLY function so it seems their own memorycopy function should work?

    Best Regards,

    Ricky Zhang

  • 0 in reply to Ricky Zhang
    TI__Guru** 115271 points
    Ricky,

    On #2 - Yes, if they are not using EXEONLY feature then they have to use their own memcopy function.

    Regards,

    Vivek Singh
  • 0 in reply to Ricky Zhang
    TI__Guru* 87145 points
    Ricky,

    Did you get any update on this debug from the customer?

    Thanks and regards,
    Vamsi
  • 0 in reply to Vivek Singh
    TI__Genius 9520 points

    Thanks, Vivek.

    They are now using their own memcopy function.

    Best Regards,

    Ricky Zhang

  • 0 in reply to Vamsi Gudivada
    TI__Genius 9520 points

    Vamsi,

    Thanks for your attention.

    Yes, I on-site supported them yesterday after the FAE summit week here (occupied for long time with the meetings and BU visits to customer :)) to debug it and found everything is correct, while customer DISABLED ECC function in their bootloader code. That's why it can not match and then error reported.

    We can closed this issue now, and thanks for your support.

    Best Regards,

    Ricky Zhang

  • 0 in reply to Ricky Zhang
    TI__Guru* 87145 points
    Ricky,

    Glad that the issue is solved.

    Are you saying that the customer did not program ECC and hence got the error when this is initially reported by you? And now, they decided to disable the ECC-check to fix the issue?

    Or Are you saying that they by mistake did not program ECC on this device and now fixed it by programming the ECC?

    Thanks and regards,
    Vamsi
  • 0 in reply to Vamsi Gudivada
    TI__Genius 9520 points

    Vamsi,

    Yes, it's the 2nd situation.

    They enabled ECC and programmed it in the past and there's no problem.

    While recently they had another problem, and when they debug that issue, they by mistake didn't program ECC but still kept ECC function enabled.

    Thanks for your help and let's get this post closed.

    Best Regards,

    Ricky Zhang

  • 0 in reply to Ricky Zhang
    TI__Guru* 87145 points

    Ricky,

    Thank you for adding the details here.  It helps.

    Thanks and regards,
    Vamsi