• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 1015 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.

Detecting illegal Memory accesses on C6x

Jake Ludgate
Prodigy 50 points
Other Parts Discussed in Thread: SYSBIOS

We have a SYS/BIOS application running on the C6678. We have not previously enabled any Memory Protection however now wish to do so after recent bug investigations have revealed illegal read/write operations (typically to address 0). The effect of these illegal read/write operations was varied; sometimes causing minor bugs, and other times causing exceptions to be raised. 

The application is generally stable and the concern is that by enabling memory protection ("Exception.enableExternalMPC = true" in the cfg file) we will generate additional exceptions due to innocuous illegal memory accesses which previously the system would have coped with fine. Ideally we would like to log these illegal memory accesses in the field without the risk of causing an exception, such that we can later retrieve this information for investigation.

We have experimented with returning from the NMI interrupt generated when the memory exception occurs, but if the guidelines regarding the conditions under which it is safe to return are followed (Section 6.2.4. in spru732j.pdf), this may not always be possible. With a simple demo app we can cause the exception to occur in the delay slots of a branch instruction, when interrupts are blocked (IB=1 in the NTSR register), which is one example of when it is not safe to return. This seems to be a perfectly feasible scenario in our actual application.

My question is therefore, is there any way to detect illegal memory accesses without generating an NMI interrupt? Is it possible to configure the memory protection module to raise a different interrupt, which would be safe to return from? Essentially, we would like to log any illegal memory accesses without introducing instability into the application.

Also, I do not have a great understanding of the relationship between the Exception module (which we seem to be able to use to detect memory accesses to invalid addresses) and the MemoryProtect module (which we haven't yet experimented with, but I presume can be used to protect access to valid addresses?). Is that broadly correct?

  • 0
    TI__Mastermind 20480 points
    Hi Jake,

    I'm not an expert on the C6x so I'll have to check with few other guys here. What version of SYS/BIOS are you using?
  • 0
    TI__Mastermind 32475 points

    Jake,

    If you enable Memory Protection, it will generate an exception for bad memory accesses that you have designated as illegal.

    We don't control which interrupt can be raised with an exception.  Exceptions all go through NMI.  SYSBIOS does not support returning from NMI (An exception) as the state of the system is compromised at that point.

    I think what you are asking "we would like to log any illegal memory accesses without introducing instability into the application" is not possible.
    How would you know a memory access is illegal if you don't have a way to designate it as an illegal access...that's sort of what Memory Protection does.
    So your statement "Ideally we would like to log these illegal memory accesses in the field without the risk of causing an exception" I do not think can be done.

    Memory Protection allows you to designate the c66 internal memory as supervisor or user "read" "write" "execute".  It utilitizes the Exception module when a bad access happens.  There are many different kinds of exceptions that can occur.  Those generated due to a bad memory access is just one type.

    I mean, we sort of do some of what you are asking in SYSBIOS witch stack checking to make sure all stack accesses are within the stack frame.
    But the stray illegal memory access can't be caught that way.

    Judah

  • 0 in reply to judahvang
    Prodigy 50 points
    Hi Judah,

    I've had some success hooking up the System events 120-125 (PMC/DMC/UMC Memory fault events) to a normal interrupt vector, and triggering an ISR to capture details of the memory fault. This seems to satisfy my requirements, does this approach seem sensible? I guess if the ISR is delayed for whatever reason then I run the risk of not capturing the IRP at the point of the fault, which is one potential drawback.

    I have one additional question regarding the RWX attributes listed against each memory section in the memory map file produced during the build. In DSP/BIOS there appears to be no way of modifying these attributes; they're always 'RWIX'. SYS/BIOS gives you the option of modifying these attributes through the platform wizard. My question is what do these attributes actually mean? I've tried playing around with changing them from the default 'RWX', however the program behaviour is always the same. Are these attributes supposed to provide some other form of memory protection? I haven't been able to find any documentation on the matter.

    Regards

    Jake
  • 0 in reply to Jake Ludgate
    TI__Mastermind 32475 points

    Jake,

    Sorry for the delayed response.  Glad you sort of found a way to do what you need to do.  I think your approach seems reasonable.

    Those memory attributes in the platform wizard do nothing on the target...So basically they're only there for the RTSC object model but have no effect on the runtime code.

    Judah