• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 29 subscribers
  • Views 494 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.

TMS570LC4357: DEVICE#49 errata / False interconnect safety checker error flag - Verifying workaround

ninja
Prodigy 250 points
Part Number: TMS570LC4357

Hello,

The conditions for DEVICE#49 are unclear to me (I may end up asking about those later...). In order to have piece of mind that I cannot ever encounter this issue, I want to verify that my MPU settings are sufficient to prevent this problem from ever occurring. Here is my (possibly faulty) plan for verification:

1) Disable MPU on my system.

2) Do a non-speculative data fetch that intentionally causes ESM group 1 channel 52 to be signaled.

3) Modify the fetch to happen only speculatively, verify that I encounter DEVICE#49 (ESM group 1 channel 52 is signaled).

4) Re-enable MPU on my system and repeat (3), verify that I don't encounter DEVICE#49 (ESM group 1 channel 52 is not signaled).

Here is my current problem -- none of my fetches (just doing CPU load instructions here) to invalid memory space seem to cause ESM group 1 channel 52 to be signaled. The ABORT handler seems to always get invoked, and I don't see the expected ESM bit set. So here are my questions:

1) How can I intentionally cause ESM group 1 channel 52 to be signaled? And:

2) Is any sample code avaiable which demonstrates the DEVICE#49 error and/or workaround?

Thanks for the support.

  • 0
    Prodigy 250 points
    Just in case it's simpler, maybe the conditions for the bug can be more precisely defined instead.

    "(1)The memory attribute is configured as normal.
    (2)There is a speculative fetch outside the valid memory range."

    Could this be more precisely defined to "If an MPU region is configured as normal access, and portions of that region fall outside the valid memory range, and then subsequently there is a speculative fetch to the portion of the region outside the valid memory range..."? Also, can you clarify what "valid memory range" means exactly?

    "(3)Multiple bus masters are configured for use."

    CPU is always a bus master, but does the other bus master need to be DMA in order for this condition to hold true? How about EMAC?

    Also does producing the error require simultaneous access / timing between CPU and the other bus master, or would we always see it regardless of memory access timing?
  • 0 in reply to ninja
    TI__Mastermind 49120 points
    Hello,

    Let me explain the issue, and then may be update the description in the document if necessary.

    There are many gaps in the 4GB address space, where any access results in an error response to the bus master making the access and an ESM error flag to be set.

    CPU also issues speculative fetches for branches to try and speed up application code execution. A speculative fetch is allowed from any memory region that is defined to be of "normal" type and from which code execution is allowed (eXecute Never - XN bit is not set in MPU for this region). One important constraint and feature of the TMS570 architecture is that these speculative fetches must not cause exceptions if the speculative fetch is not actually used (incorrect branch prediction).

    The issue described in this erratum, device #49, is that a speculative access to an invalid memory region of "normal" type still causes an exception flag to be set.

    The workaround is then to use the MPU to clearly define the memory regions from where code execution is allowed (includes speculative fetches).

    Hope this helps.

    Regards,
    Sunil
  • 0 in reply to Sunil Oak
    Prodigy 250 points
    Thanks Sunil. So to summarize:

    - Speculative fetches will only occur from MPU regions with BOTH memory type = "normal" and XN = 0.
    - If I ensure all such defined regions contain only valid memory space (not gaps which may trigger ABORT or ESM errors) then I can avoid DEVICE#49.
  • 0 in reply to ninja
    TI__Mastermind 49120 points
    Yes, that is correct.

    Regards,
    Sunil
  • 0 in reply to Sunil Oak
    Prodigy 250 points

    Hi Sunil,

    One related question. The chip power-on default is for MMU to be disabled with no MPU regions defined. In this state, is it possible for DEVICE#49 to be encountered? Basically, I'm wondering if I need to take care to turn on MPU very early in the boot process (before initializing other bus masters?).

    Thanks again.

  • 0 in reply to ninja
    TI__Mastermind 49120 points
    Hi,

    When MPU is not enabled, there is still a default memory map that is applicable. This is defined on page 191 of the Cortex R5 TRM version r1p2. As you can see there are several regions that are of "normal" type and from where code execution is allowed.

    Regards,
    Sunil