• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 653 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.

TMS320F28377S: RAM March Copy Test - SafeTI library

Santhosh Nandakumar
Intellectual 260 points
Part Number: TMS320F28377S
Other Parts Discussed in Thread: C2000WARE

Hi,

I am using TI Safe-TI STA for doing set of Diagnostic Tests on my custom TMS320F28377S PCB. This query is particularly regarding one test, STA_MARCH_COPY 

  1. Running without any fault injected - This test works without any issue. The Process i see is,
    1. Note that am running this test on GS0 (0x00C000, ramfuncs) for 64 32bit words only for initial testing. - I tired it on the ebss RAM also, result is same as below...
    2. Start By Copying content from Test Address (for the length) to Copy Address 
    3. Apply the March Test with the PATTERN Selected
    4. Copy back the content from Copy Address to Test Address.
    5. Check Memory Error using STL_March_checkErrorStatus() and call PASS/FAIL
    6. This test results in a PASS. Content restored back to the address.
  2. Running the test with fault injected. 
    1. Here the test is run on the same memory as above.
    2. Error injected using an xorMask - 0x00000001. I can see one bit flipping in the first word after this satement.
    3. Following this the code starts the March Function (which is an asm file)
    4. I stepped through the asm file and code go no further than aAscend section... the code ends up in undefined memory and stops. I am not sure why !

Any reason why code fails at the point indicated in Point 2.d. Am stuck with this for several days now. Any help would be great. I cant share the whole project here, but i can definitely share the diagnostics test code sections if need be. Please help me out on this. This is tied to a Regulatory UL1998 test which is coming up in few weeks. I need grip on this before that.

  • 0
    Intellectual 260 points

    Hi All, Still waiting for some help.... Please do let know any indicators.

    Thanks

    Santhosh

  • 0 in reply to Santhosh Nandakumar
    TI__Expert 7985 points

    Hi Santosh,

    We are looking at this issue and will get back to you shortly.  Thanks, Krishna

  • 0
    TI__Guru 52555 points

    Can you give me more information about this "undefined memory" location? What address is it jumping to? What does the disassembly window or .map file show at that location?

    Does it seem like you're getting an interrupt with an unregistered handler? If you look at PIECTRL in the CCS registers window, can you identify what was the most recently fetched vector?

    Whitney

  • 0 in reply to Whitney Dewey
    Intellectual 260 points

    Hi Whitney,

    This is my disassembly, its a ESTOP

    and debug shows

    and with respect to PIECTRL, is this what you were referring to ?

    In the meanwhile...

    I took the original TI test code for Diagnostics - ti\c2000\C2000Ware_1_00_01_00\libraries\diagnostic\f2837xs\examples (i had built my code based on this)

    and just changed the d1ram section from RAMD1 to RAMGS0. ramfuncs is assigned to (RAMGS0 | RAMGS1) and ran the test for enableErrorInject = 1.

    The code stops exactly at the same place where it used to when i test it with my code. I had to do this to make sure that the issue is not related to my functional code.

    Do let know if am doing anything wrong or am missing something here...

    Thanks

    Santhosh

  • 0 in reply to Santhosh Nandakumar
    TI__Guru 52555 points

    So I think the difference is that D1 has ECC and can correct a single bit error, but GS0 has parity and cannot and will generate an NMI as a result. 0x3fe2ed is in the boot ROM, so it seems you're getting a reset. Do you have an NMI handler registered?

    Whitney

  • 0 in reply to Whitney Dewey
    Intellectual 260 points

    Hey Whitney,

    Oh I get it. I went through the TRM regarding this and understand that a parity error on GS0-GS15 and LS0-LS5 is not correctable and raises an NMI ISR. Is this correct ?

    In this case the STL test code dosent configure any NMI for this test. That should explain why its resetting i guess.

    But suggest this is detailed in a line or two in the Diag Library Documentation, where it says the test can be applied to any RAM.

    Could you suggest which test case i use to test the RAM DC Fault Test ? I also have the RAM_LOGIC and RAM_DETECT test cases in the Safe-TI STA.

    I have had past reference to March13N test for this. If i do have to use this, i have to keep the NMI ISR implemented and then correct the injected error from there ? 

    Thanks

    Santhosh

  • 0 in reply to Whitney Dewey
    Intellectual 260 points

    Dear Whitney,

    Some more updates. When i enabled the NMI for uncorrectable memory error, the code did jump to ISR instead of reset.

    Thanks

    Santhosh

  • 0 in reply to Santhosh Nandakumar
    TI__Guru 52555 points

    Glad to hear that explained the issue. Not knowing what requirements you're trying to meet, I can't really make a recommendation as to whether just relying on using the parity/ECC or if the March test is needed. Have you seen this app note? www.ti.com/lit/SPRACB9

    Whitney

  • 0 in reply to Whitney Dewey
    Intellectual 260 points

    Dear Whitney,

    I guess "C2000™ SafeTI™ Diagnostic Library for TMS320F2837xD, TMS320F2837xS, and TMS320F2807x" versionn 1.00.02.0 and www.ti.com/lit/SPRACB9

    are more or less the same document, and both are last edited in 2017 end. Thanks for the reference, i will go through this to understand if there is any difference.

    To clarify my question..

    If i understood it correctly, traditionally the March test is performed by writing a pattern and reading back the same to compare and identify if there is a bit error (DC fault). Once this hits a threshold, manually a fault is raised to stop functional operation.

    I also understand that the Memory Controller Module in these processors can do this test by default and raise an interrupt if a write/read happens into/from one such address/data with a bit/parity error. So that to keep this functionality running continuously, i just have to configure the BIT/PARITY ERROR ISR ?

    Apologies for a few (may be) simple questions, i am implementing this for the first time and see a difference from the IEC60370 STL libraries which were used for the PICCOLO processors etc.,

    The indicator which you pointed out was extremely helpful for me to understand what was happening and make a move.... Thanks.

    Thanks and Regards

    Santhosh