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

Dabort in checkRAMECC

David Sabol
Genius 4850 points
Other Parts Discussed in Thread: HALCOGEN, TMS570LS0332, TMS570LS20216

Specifically it seems to be the line

ramread = tcramA1bit;

I haven't had trouble with this until I started writing my own het program, but I don't see how I could be doing something that would affect the self test

 

    /* Force a double bit error in both the banks */
    _coreDisableRamEcc_();
    tcramA2bitError ^= 3U;
    tcramB2bitError ^= 3U;
    _coreEnableRamEcc_();

    /* Read the corrupted data to generate double bit error */
    ramread = tcramA2bit;
    ramread = tcramB2bit;

    regread = tcram1REG->RAMUERRADDR;
    regread = tcram2REG->RAMUERRADDR;

  • 0
    TI__Guru 59540 points

    Hello David,

    Can you check to make sure you have ECC initialized/enabled in both the CPU and the Flash wrapper? This type of error is generally a result of having the ECC initialized in the CPU but not in the flash wrapper logic.

  • 0 in reply to Chuck Davenport
    Genius 4850 points

    Hi Chuck,

     

    I believe I do, I have attached a picture with my settings in Halcogen.

     

  • 0 in reply to David Sabol
    TI__Guru 59540 points

    David,

    When you get the abort, can you have a look at the RAMUERRADDR register to see if there is a recorded address that generated the error since the code snippet you provided shows that a double bit error is being generated (although you initial suspected read was the single bit error location).

    If it is the single bit error location, please look at RAMSERADDR register.

    Information regarding these registers is located in sections 5.6.6 and 5.6.7. You may also want to check the RAMERRSTATUS register to get additional information.

    Let me know what you find.

    RAMSERRADDR

  • 0 in reply to Chuck Davenport
    Genius 4850 points

    What document are you referring to?  I have a copy of the TRM (SPNU489B) but the registers are described in ch. 4. Maybe I have an old copy.

     

    For the register values:

    Under RamWrapper_Even

    SErrAddr - 0x00000000

    UErrAddr - 0x00000010

    ErrStatus - 0x00000000

     

    Under RamWrapper_Odd

    SErrAddr - 0x00000008

    UErrAddr - 0x00000018

    ErrStatus - 0x00000000

  • 0 in reply to David Sabol
    TI__Guru 59540 points

    Hi David,

    Sorry, I should have indicated that I was looking at the TRM for the TMS570LS0332 which is SPNU517A. I used this as reference because the screen shots you provided show that you are using Halcogen with a project for this device. However, the TRM you reference is for an older device, TMS570LS20216, which is based on a different silicon technology (90nm process vs. 65nm process).

    Can you clarify which part number you are using?

    In the meantime, can you check if the addresses indicated in the single and uncorrectable error address registers correspond to the addresses of the ECC test variables in your original post?

  • 0 in reply to Chuck Davenport
    Genius 4850 points

    Sorry for the confusion.  I am using the TMS570LS0332.  I thought the TRM I was using was generic to the family.

    tcramA2bit -> 0x08000010

    tcramB2bit ->0x08000018

    I went back to an older version of code before I made my recent changes.  It seems that the data abort is hit 3 or 4 times, but then after that the code runs OK and the rest of the program executes, which is why I hadn't noticed it until I set a breakpoint on the dabort error.

  • 0 in reply to David Sabol
    TI__Guru 59540 points

    Hi David,

    So the content of the RAMUERRADDR registers contains the addresses of the known errors. This is expected and the correct reaction is a DABORT. As far as I recall, the Halcogen code should be setup to handle this and clear the error, restore the corrupt memory locations so that they no longer will cause an ECC error.

    Perhaps this is true except for the DABORT handler which would need to have your code added to handle the exception to the rule. i.e., since these DABORTs are expected, you could set a global flag to indicate that the test was ran and that the DABORT is an expected result and, in fact, is an appropriate result of test.

    It's worth noting that there are several steps to clear the ECC error/DABORT. First is to clear any flags that are set in the RAM wrapper, clear any flags that are set in the ESM, and to perform a CPU read of the UERRADDR registers since leaving these set will cause any future double bit errors to be missed/not captured.

    What version of Halcogen are you using? Perhaps it might make sense to update to the latest and see if the newer version handles the test more gracefully. I recall that there have been improvements in this area.

  • 0 in reply to Chuck Davenport
    TI__Guru 59540 points

    David,

    I forgot to mention that most of our devices have device specific TRMs since, although they are mostly similar, there may be deprecated IP or changes in IP versions between devices/silicon sets. In the case of the TRM you were using, this is a very early version of the Hercules devices and used a different flash technology and thus a different Flash wrapper. almost all of the other IP/modules on the device will port but it is best to match the TRM and device. Generally speaking, a device/silicon specific TRM will be linked to from the product page for the device on ti.com.