• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 955 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.

66AK2G12: Sticky error in EDMATC_ERRSTAT Register

Naoki Kawada
Guru 19890 points

Part Number: 66AK2G12

Hi,

My customer noticed that MMRAERR on EDMATC_ERRSTAT register was sticky even if they clear the bit via EDMATC_ERRCLR register.
I recreated the same problem on my EVM, see below:

1. launch CCS and connect to C66 core with default gel file and then open memory browser. If you navigate EDMATC_ERRSTAT register, MMRAERR has been set by default. Not that EVM has been powered with No Boot configuration.

2. Try to clear the bit via EDMATC_ERRCLR register

3. The bit looks cleared ...

4. But if you update the window, the error raised again.

For now, they has been able to use EDMA normally on their board, but how should we handle this error ?

Best Regards,
NK

  • 0
    TI__Guru* 95265 points
    NK,

    I tried the same setup of a K2G EVM in no-boot mode and default GEL and used C66x core to poke 0x2760120, 124 and 0x128 register.

    - 0x120 is read-only and I saw it has BIT 3 set by default, I can't write
    - 0x124 I can write 1 to BIT 3 or write 0 to BIT 3
    - 0x128 I tried to write 8 to clear the BIT 3 on 0x120, it has no effect (different from your observation)
    - 0x12c (ERRDET) this is always 0 and it didn't record anything

    This BIT 3 of ERRSTAT is sticky, I have no way to clean it. The question is, with this bit always set, does this cause any problem to the EDMA transfer? How do you plan to use this bit?

    Regards, Eric
  • 0 in reply to lding
    Guru 19890 points

    Hi Eric,

    Thank you for the confirmation on your setup. It seems that was slightly different from my experiment, but i believe the existing issue should be same. 
    As for the correctness of transfer, no problem so far, but my customer has to abandon the error interrupt related to MMRAERR if you say this is HW bug. What do you think ?

    Best Regards,
    NK

  • 0 in reply to Naoki Kawada
    TI__Guru* 95265 points
    Hi,

    If your customer wanted to use MMRAERR related EDMA error interrupt, it will not work properly. Let me check if any way we can clear this bit.

    Regards, Eric
  • 0 in reply to lding
    Guru 19890 points

    Hi Eric,

    Ok, you are still finding the way to clear the error bit... Please let me know your findings. At the same time, please also check if this sticky error never affects to the correctness of normal transfer in design (I believe this is more important than clearing the error bit).

    Best Regards,
    NK

  • 0 in reply to Naoki Kawada
    Guru 19890 points
    Hello Eric,

    Any response ? I'm still waiting for your reply.

    Best Regards,
    NK
  • 0 in reply to Naoki Kawada
    Guru 19890 points
    It takes long time to resolve the thread. Could you please let me know your answer very soon. My customer is waiting.
  • 0 in reply to Naoki Kawada
    Guru 19890 points
    Eric, What is your progress on this ? It`s your turn. How we should handle this issue ?
  • 0 in reply to Naoki Kawada
    TI__Guru* 86095 points
    Hello Kawada-san
    We apologize for the delay in response. Eric was seeking help from IP experts on this.

    This is a known deficiency in the EDMA3 IP , you will find some older posts on this on other devices and it applies to K2G too

    e2e.ti.com/.../104441
    e2e.ti.com/.../292964

    It is likely that when you pull the memory window in CCS, you are also accessing some reserved configuration address in TC memory map, that is causing this error.

    In non CCS environment, I do not think you will see this error , unless the program code is accidentally accessing config memory map in TC that is marked as reserved etc.
    Second post has some more guidance.

    Let me know if you have more questions - I am marking this post as resolved, but please feel free to reopen if you have follow up questions/
    REgards
    Mukul
  • 0 in reply to Mukul Bhatnagar
    Guru 19890 points
    Hi Mukul and Eric

    Thanks for your investigations. Ok, that was caused by unintentional read against for some reserved registers via memory window, right ?
    It seems i can not access the posts you suggested because of something like permission error.
    Can you briefly summarize the details here ?

    Best Regards,
    NK
  • 0 in reply to Naoki Kawada
    TI__Guru* 86095 points
    Hi Kawada-san
    Here is a snapshot from internal spec

    --
    In addition, both functional and emulation accesses to invalid address ranges will cause the MMRAERR
    status bit to be set. An interrupt will be generated if enabled. Note that this is not ideal as normally a user
    would not desire the an error to be logged for accesses to be generated by emulation accesses. This issue
    can be avoided by:
    • user can mask reserved address ranges in CCS such that emulator will never access reserved
    range
    • user can disable interrupt generation for MMRAERR bit if desired (of course, this will mask
    errors for functional access)
    ---

    Essentially CPU accesses in normal/functional mode or emulation mode (e.g. CCS access - emulate reads) to areas within CC or TC memory map that are reserved, will cause the MMRAERR bit to be set.
    So in your case when customer is reading TC memory map in memory window, they will see this bit get set.

    Hope that helps.
    Let me know if you have more questions
    Regards
    Mukul

    NOTE: Sorry about the bad links, those posts are internal only and will not be visible to external users, but I have captured the spec description above from those posts