• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 85 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.

Original question:

TMS570LC4357: C0_RX_PULSE Interrupt Triggers CCM Errors in ESM

TMS570LC4357: VIM ECC Fallback Vector Address (FBVECADDR) Test

Benjamin Roytburd
Intellectual 300 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Tool/software:

Is there a way to trigger the FBVECADDR during VIM ECC testing? To confirm that the handler works? This would be the vimECCErrorHandler in the TI HalCoGen.

In the TRM, it is stated that:

The UERR indicates that a double-bit error has been found and that the Interrupt Vector Table is
bypassed. The resulting vector of any IRQ/FRQ interrupt is then the value contained in the
FBVECADDR register until this bit has been cleared.

In 19.9.1 Interrupt Vector Table ECC Status Register (ECCSTAT), but when I triggered a UERR, then attempted to trigger an IRQ/FIQ, I did not see the function at FBVECADDR get called. Is there a formal way to test this at all?

Thanks,
Ben

  • 0
    TI__Guru 73771 points

    Hi Ben,

    Apologies for the delayed response.

    I never tested this scenario before.

    I used our TI internal AI which can verify all the documents associated with this controller and also verifies all the old similar issues in the database and will provide useful suggestion. On first level i used this tool and got below suggestions, so i am requesting you to try this method once and let me know if you need further support on this:

    The situation is complex and requires careful consideration. Here's what we know and what can be attempted:

    1. Default Behavior: According to the TRM, when a UERR (uncorrectable error) is detected, the Interrupt Vector Table should be bypassed and any IRQ/FIQ interrupt should vector to the address contained in the FBVECADDR register until the UERR bit is cleared.

    2. Testing Approach: While there isn't a direct documented method to test this functionality, here are some potential approaches:

    a) Diagnostic Mode Testing: As mentioned in some related cases (6), you can use diagnostic mode to test ECC-related functionality. This would involve:

    • Writing data and corresponding ECC to the flash
    • Deliberately corrupting either the ECC or data to create multiple bit errors
    • The SEC/DED module should detect these errors

    b) ESM Integration: Since ECC errors are typically handled through the Error Signaling Module (ESM), you might want to:

    • Configure the ESM for proper error handling (4)
    • Enable the appropriate error notifications
    • Monitor ESM status registers when errors occur
    1. Important Considerations:

    a) Error Types:

    • Group 2 and Group 3 errors will always trigger the nERROR pin by default (4)
    • The ESM module can be used to verify error detection (1)

    b) Interrupt Handling:

    • The VIM (Vectored Interrupt Manager) maintains an interrupt stack (7)
    • When interrupts are cleared by reading the VIM vector registers, proper context should be maintained

    1. Suggested Test Procedure:

    2. Set up the vimECCErrorHandler in FBVECADDR

    3. Configure the VIM for proper ECC error detection

    4. Create a controlled test environment where you can:

      • Inject a double-bit error in the vector table
      • Trigger a test interrupt
      • Verify if the handler in FBVECADDR is called

    5. Potential Issues: If you're not seeing the FBVECADDR handler being called, check:

    • Whether the UERR is being properly set
    • If the interrupt priorities are configured correctly
    • If there are any competing interrupt handlers

    --
    Thanks & regards,
    Jagadish.