SystemMMU

I see only a statement.  What is your question?

Hi

On my J5EVM, I don't get the expected result when I write into a memory region that I have configured to generate MMU fault. Instead of getting an IRQ, the DSP completely stalls.

So my question is, Is this an known issue with the J5EVM Beta boards?

If not, is there any available example code that I can compare to my own implementation?

BR

Niklas

Thank you for clarifying.  This is a good question.  In the past devices the System MMU interrupt was routed only to the Cortex A8 (and not to the DSP itself).  In that case when a fault occurred the DSP would stall, same as you are seeing, and the Cortex A8 was expected to do error handling.  For example, it might reset the DSP subsystem or something along those lines.  I assume that method will still work.

I will need to ask around to see if someone knows of something in particular that needs to be done to force the DSP to abandon the memory access and take the interrupt.  My guess is that because the memory access is stalled that is making it impossible to get into the ISR.  I'll see if someone else can chime in with some more info and hopefully a solution to make it work.

Best regards,
Brad

NIklas,

How are you configuring the System MMU, i.e. are you enabling TWL or simply using the 32 entries in a static configuration?

Which specific System MMU interrupt is being triggered, i.e. can you read MMU_IRQSTATUS from the ARM after the interrupt/hangup occurs?

Brad

Hi

I got a confirmation from Manfred Christ, a TI FAE in germany, that my reported systemMMU issue has been verified within TI. The DSP stalls completely on a MMU fault. Also, systemMMU softreset isn't working either. And both these issues are present in the latest PG2.1 silicon. Manfred said it would be possible to read out the MMU registers from cortex-A8 side, but what I can see, MMU_FAULT_PC isn't correctly updated. This means that you don't know on which line in your code the MMU fault occured. MMU_FAULT_AD seems to be updated correctly, i.e. to which address the faulty read/write occured, but that isn't as usable as MMU_FAULT_PC

I have sent my example code to Manfred. Should we continue this issue on this forum, or should I discuss it only with Manfred?

BR

Niklas  

Niklas Persson said:

my reported systemMMU issue has been verified within TI. The DSP stalls completely on a MMU fault. Also, systemMMU softreset isn't working either.

This is the expected behavior.  When a translation fault occurs the access never completes.  So it's expected that the DSP stalls in this scenario.  You would need to soft reset the DSP not the MMU in order to get back to a workable state again.  We're still trying to hammer out some of the details, but I believe another option might also exist.  Specifically, if the ARM were to actually insert a mapping into the System MMU then you could actually make the access complete on the DSP and then get into the ISR on the DSP side to debug things further (e.g. look at IRP register to see value of PC at time of MMU interrupt).

Niklas Persson said:

but what I can see, MMU_FAULT_PC isn't correctly updated.

We need to remove that register from the TRM as it was not implemented on this device.

Niklas Persson said:

Should we continue this issue on this forum, or should I discuss it only with Manfred?

Perhaps ask Manfred to join the discussion on the forum.  That way others can benefit from the discussion as well.

If you connect to the DSP core (prior to the fault!) you can set a "watchpoint" on the address causing the MMU fault, i.e. the value of MMU_FAULT_AD.  Just go to View -> Breakpoints.  Then set a new watchpoint with the value of MMU_FAULT_AD (hopefully it's consistent!).

Thanks for the tips, it might come in handy

BR

Niklas

Manfred tried using the watchpoint and unfortunately it stalls before it can break, so that didn't work either.

Hi

More updates on the SystemMMU issue.

I see a new issue, where the DSP completely stalls on a fetch of an interrupt vector. The issue only occurs when table walk logic is enabled.  If I load the allowed pages into the TLB manually and use the MMU without  table walk logic enabled, the issue never occurs.

My idea is that this issue occurs if the page where the interrupt vector table is located isn't present in the TLB when the interrupt occurs, but I haven't been able to verify that.

Any progress with the previous issue?

BR

Niklas

Niklas Persson said:

Any progress with the previous issue?

In the case where a System MMU error occurs during a DSP data/instruction access it is required for the ARM to intervene.  There is no way around it.  Only after the ARM has "fixed" the table and then written to the System MMU's interrupt status register will the DSP access complete and allow the DSP to continue operation.

Niklas Persson said:

I see a new issue, where the DSP completely stalls on a fetch of an interrupt vector. The issue only occurs when table walk logic is enabled.  If I load the allowed pages into the TLB manually and use the MMU without  table walk logic enabled, the issue never occurs.

What error is reported in the System MMU?

Hi

So this is the official solution, that ARM will have to catch the MMU fault and patch the TLB?. With my discussion with Manfred Christ, it sounded like this issue will be fixed in future revisions of the chip, since this behaviour isn't the intended. Has the fix been verified? If so, could you then provide me with the source code, showing how the fix is implemented. 

The systemMMU doesn't report any interrupts when the second issue occurs

BR

Niklas

Niklas Persson said:

So this is the official solution, that ARM will have to catch the MMU fault and patch the TLB?

Correct.

Niklas Persson said:

With my discussion with Manfred Christ, it sounded like this issue will be fixed in future revisions of the chip, since this behaviour isn't the intended.

No, this is the intended/expected behavior.  It will be clarified in future revisions of the documentation.  There is no fix since this is the expected behavior.

Niklas Persson said:

The systemMMU doesn't report any interrupts when the second issue occurs

Any new info regarding your second issue?  Sorry, but nothing came to mind with the info you already provided.  Perhaps double check that the table and the table walking logic is configured correctly.