• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 914 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:

Safety Demo on TMS570LS04x launchpad: NHET parity error triggered at unexpected line of code

RM48L950: HTU Parity Address Stuck

Guy Tadi
Intellectual 660 points
Part Number: RM48L950
Other Parts Discussed in Thread: HALCOGEN

I'm running parity error test on HTU1. I'm able to generate the parity error OK and it's correctly flagged by PEFT in the PAR. However, the PAOFF seems stuck at 0x001 and so when I compare with the actual faulted address "#define htu1RAMLocVar ((uint32)0xFF4E0004U)" for SL API, I get an address mismatch and the test fails. Th

The PAOFF in HTU1 is stuck at 0x001 after Halcogen sysInit() (specifically after periphInit() in system.c which merely releases the peripherals from reset). Because of this I can't get the correct parity error address even though PEFT is set on error as expected. I've tried reading the entire 32-bit PAR as suggested by the TRM but that doesn't unfreeze it. The TRM has a note that "The Parity Error Address bits will not be reset, neither by PORRST nor by any other reset source." How do I get around this?

I believe I'm seeing similar behavior with DMA parity test although that only fails on the first test - subsequent tests are OK. Any thoughts will be greatly appreciated.

  • 0
    TI__Guru**** 196776 points
    Helo Guy,

    The PAOFF is parity error address offset. If your swap bit 0 of the parity data at 0xFF4E0204 at test mode, when you read the data from HTU RAM at 0xFF4E0004, you will get a parity error, the error address (PAOFF) should be 7. PAOFF=0x001 is not correct.

    This error address will not be cleared by reset or by reading this register. The PAOFF value will not affect device operation if the error bits (ESM1.8, and PEFT bit in PAR register) are cleared.

    #if ((__little_endian__ == 1) || (__LITTLE_ENDIAN__ == 1))
    #define htu1RAMParLoc ((volatile uint8 *)0xFF4E0207U)
    #else
    #define htu1RAMParLoc ((volatile uint8 *)0xFF4E0204U)
    #endif
    #define htu1RAMLocVar ((uint32)0xFF4E0004U)
    #define htu1RAMLoc ((volatile uint32 *)0xFF4E0004U)

    Please change #define htu1RAMParLoc ((volatile uint8 *)0xFF4E0207U)
    to #define htu1RAMParLoc ((volatile uint8 *)0xFF4E0204U)

    I just noticed this. This may be a SW bug. Please do a test, and let me know if the change makes your test work.
  • 0 in reply to QJ Wang
    Intellectual 660 points

    The PAOFF is still 0x001 after this change. I confirmed that the parity bit at 0xFF4E0204U is flipped to a "1" after this change but my test still didn't work.

    Before executing the line below

            /* Cause parity error */
        ramRead = (*htuRAMLoc);

    with htuRAMLoc = 0xFF4E0004. The PAR content is

    PEFT = 0

    PAOFF = 0x001

    Immediately after executing ramRead = (*htuRAMLoc); line, the PEFT = 1 but PAOFF stays the same. See screenshot below.

    Is there anything else I should try?

    BTW: I'm not working with HTU2 now, but for HTU2 should #define htu2RAMParLoc ((volatile uint8 *)0xFF4C020BU) be also changed to #define htu2RAMParLoc ((volatile uint8 *)0xFF4C0208U) if HTU1 is a bug?

    #if ((__little_endian__ == 1) || (__LITTLE_ENDIAN__ == 1))
#define htu2RAMParLoc   ((volatile uint8 *)0xFF4C020BU)
#else
#define htu2RAMParLoc   ((volatile uint8 *)0xFF4C0208U)
#endif
#define htu2RAMLocVar       ((uint32)0xFF4C0008U)
#define htu2RAMLoc      ((volatile uint32 *)0xFF4C0008U)
#endif

  • 0 in reply to Guy Tadi
    Intellectual 660 points

    I'm still waiting for a response so that we can move on with our development. Please let me know if there is anything else I can look at or do to get past this issue. Thanks.

  • 0 in reply to Guy Tadi
    Intellectual 660 points
    Anyone, please? Guru, TI Employee, others... I must move past this issue soon. Thanks.
  • 0 in reply to Guy Tadi
    Intellectual 660 points
    TI, please... I wish this were my pi hobby project where I could wait indeterminate amount of time for support, but unfortunately it is not. Real projects, release schedules, and real customer commitments depend on developers making progress on this Hercules based product development. I don't have the luxury of picking up the phone to call my local FAE like I would do with your competition and that my first and follow-up posts being on Saturday and Sunday respectively should tell you something. I like this E2E forum, but please respond even if you can't help so I know what to do next and move on.
  • 0 in reply to Guy Tadi
    TI__Guru* 83845 points
    Hi Guy
    We apologize for the delay. QJ got tied up on another critical issue.
    We will need to get back to you on this - do note that Monday is a US holiday and it may take us longer to respond back.
    However we will get back to you on what guidance we can provide on this.

    Regards
    Mukul
  • 0 in reply to Mukul Bhatnagar
    TI__Guru**** 196776 points

    Hello Sir,

    I repeated HTU1 parity test many times on RM48 HDK, and I got the correct PAROFF for all the tests:

    1.    To generate parity error for data bit 0 of 0xFF4E0000, the address offset of the parity error is 0x03

    2. To generate parity error for data bit 8 of 0xFF4E0000, the address offset of the parity error is 0x02

    3. To generate parity error for data bit 16 of 0xFF4E0000, the address offset of the parity error is 0x01

    4. To generate parity error for data bit 0 of 0xFF4E0004, the address offset of the parity error is 0x07

    5. To generate parity error for data bit 16 of 0xFF4E0004, the address offset of the parity error is 0x05

    Any questions?

    I will try the SDL later.

  • 0 in reply to QJ Wang
    TI__Guru**** 196776 points

    Just check the MPU setting of the SDL example code. The MPU for 0xFF000000 memory region is device mode, please change it to strongly-ordered mode:

  • 0 in reply to QJ Wang
    TI__Guru**** 196776 points

    Hello Sir,

    Did HTU1 RAM parity test with SDL, it works fine:

    BTW, htu1RAMParLoc ((volatile uint8 *)0xFF4E0207U) in SDL is correct. I didn't notice it is uint8 last time.

  • 0 in reply to QJ Wang
    Intellectual 660 points
    Thanks QJ. MemoryInit of HTU seems to have solved my problem. Why must the memory be configured as strongly ordered? It's still DEVICE_NONSHAREABLE. Must I change this STRONGLYORDERED_SHAREABLE?