• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 3 answers
  • Subscribers 30 subscribers
  • Views 597 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.

TMS570LS3137: How to differentiate HET parity errors amoung 2 modules

sreenivasan m
Genius 3705 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN

Hi Team,

ESM group1 channel 7 is asserted when parity error is detected in N2HET1/N2HET2 module. But, how to differentiate the error between N2HET1 ad N2HET2? Could see that HETPAR will hold the offset value from start of the HETRAM. So, how can we differentiate the source of error (not by using HETPPR register)?

  • 0
    TI__Mastermind 21425 points

    Hello,

    When parity error is detected, the N2HET address, which generated the error is detected and is captured in HETPAR. For N2HET1 the offset is FFF7 B878h and for N2HET2 the offset is FFF7 B978h.

    Parity Pin Register (HETPPR - N2HET1: offset = FFF7 B87Ch; N2HET2: offset = FFF7 B97Ch) allows HET pins to be configured to drive to a known state. All N2HET pins selected by N2HET Parity Pin Register (HETPPR) enter a predefined safe state.

  • 0 in reply to Miro
    Genius 3705 points

    Hi Miro,

    Can you recheck the TRM document, since HETPAR provides only offset information.

    12-2 PAOFF Parity Error Address Offset. This register holds the offset address of the first parity error, which is detected in N2HET RAM. This error address is frozen from being updated until it is read by the CPU. During emulation mode, this address is frozen even when read. In case of a N2HET RAM parity error, PAOFF will contain the offset address of the erroneous 32-bit N2HET RAM field counted from the beginning of the N2HET RAM. Examples: The 32-bit program field of instruction 0 will return 0, the 32-bit control field of instruction 0 will return 1, ..., the 32-bit control field of instruction 1 will return 5, and so on.

    Read: Returns the offset address of the erroneous 32-bit word in bytes from the beginning of the N2HET RAM.
    Write: Writes have no effect

  • 0 in reply to sreenivasan m
    TI__Mastermind 21425 points

    Hi,

    I your first post you mentioned two registers: HETPAR and HETPPR.

    So, yes. HETPAR provides only offset information and that is what I wrote in my first post.

    And HETPPR allows HET pins to be configured to drive to a known state. I don't see any discrepancy.

  • 0 in reply to Miro
    Genius 3705 points

    Thanks Miro. My question was how do we differentiate whether the error is coming from HET1 or HET2 module, if we get HET parity error?

  • 0 in reply to sreenivasan m
    TI__Mastermind 21425 points

    Hello,

    You can do this by reading HETPAR register  ( For N2HET1 the offset is FFF7 B878h and for N2HET2 the offset is FFF7 B978h ).

  • 0 in reply to Miro
    Genius 3705 points

    Hi Miro,
    Let me explain a bit more:

    1. We have 2 HET modules and same error channel is tagged to these module when parity error is detected.
    2. Now, HETPAR contains only the offset address. What is the default value in HETPAR when no error is detected?

    The requirement is that when HET parity error is detected, after reading HETPAR register (as it contains only offset details), how do we identify whether error is from HET1 or HET2 module?

    What is the default value on this register after reset? Since, zero also considered to be correct offset address.


    Hope you understood the question.

  • 0 in reply to sreenivasan m
    TI__Mastermind 49120 points

    Hi Sreenivasan,

    Parity error signals from two HET modules are wire-OR'ed and connected to the same ESM group1 channel 7 status flag. When this error is signaled the application must read from the parity error address register for both HET modules, one after another, to identify which HET module caused the parity error signal to be generated. You can intentionally cause a HET RAM parity error at an unused HET RAM address (probably the last address in the available HET RAM) to "initialize" the parity error address registers in both HET modules. This register is not initialized to any value on any reset condition, so any initial value cannot be counted on to be the state on subsequent power-ups.

  • 0 in reply to Sunil Oak
    Genius 3705 points

    Hi,

    Let's take an example that we have 2 HET modules configured and encountered parity error only on one HET module. Please explain how do we differentiate the error module with other one.

  • 0 in reply to sreenivasan m
    TI__Mastermind 49120 points

    Hi Sreenivasan,

    Suppose that as part of your check of the parity error detection for the HET RAM, you have used the HET1 RAM address 0xFF4609F0 as the location in HET1 RAM and 0xFF4409F0 for HET2 RAM where you will intentionally cause parity errors using the hetxParityCheck() routine. This is the address for the program field of instruction # 160, the max supported on TMS570LS3137. Let's assume that you do not use all 160 instructions in your HET programs. (Side note: HALCoGen uses address 0xFF460000 for this check on HET1 RAM, which should be corrected.)

    This parity error check routine will cause the Parity Address Register (PAR) inside HET1 and HET2 to contain 636 or 0x27C in the PAOFF field.

    Let's say that you have a parity error in HET1 RAM during the application, say from the control field of instruction 1. This sets the ESM group 1 channel 7 status flag, which generates an interrupt to the CPU (if enabled). The ISR reads the ESM group1 error status register to identify it as an HET parity error first. Then it reads from the HET1 and HET2 PAR registers to see if the content of the PAOFF field has changed from 0x27C. In this example, the HET1 PAR register's PAOFF field will have a value of 5, indicating a parity error in the control field of instruction 1. The HET2 PAR register should still contain 0x27C in the PAOFF field, indicting no parity error in HET2 RAM.

    Hope this helps.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Genius 3705 points

    Hi Sunil, 

    If we use complete HET memory and both HET modules are used and we get errors on both HET modules at sametime. Then there is every possibility of missing or treating the error as it was due to self test. Can you please check and if required add an errata to fix this issue.

    Regards,
    M.Sreenivasan.

  • 0 in reply to sreenivasan m
    TI__Mastermind 49120 points

    Hi Sreenivasan,

    This is only an issue if every single memory location in the available memory is used. It does not depend on whether you use both HET modules or not.

    I will file a bug report for this.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Genius 3705 points

    Thanks Sunil.

    Will there be an errata for this or in which version it will be fixed, can you please share the details.

    Regards,
    M.Sreenivasan.

  • 0 in reply to sreenivasan m
    TI__Mastermind 49120 points

    There is no fix planned. Also the original issue is with the design specification itself, so there is no erratum filed. As I explained, the issue occurs if and only if every single available word of both HET RAMs is used, and if a parity error occurs in the word in the last row in both HET modules. I was incorrect in my earlier post about there not being a dependency on the issue being in both HETs.

    Regards, Sunil