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

DSP MMU Error Fault!

Filippo Cona
Intellectual 450 points

Other Parts Discussed in Thread: OMAP3530

I need to run an image processing application on my DM3730 dual core (ARM/DSP).

I'm using dsplink 1.65.2.9 and thanks to support obtained from a previous post I managed to
modify the memory mapping of the example loop to send and receive 4MB data buffers between the ARM and the DSP.

So now I've integrated my image processing algorithm inside the example dsp-side and I can execute only a small part of it (by commenting the most computationally intensive sections). If I try to run a bigger part of the algorithm I get this message:

[11015.449981] DSP MMU Error Fault!  MMU_IRQSTATUS = [0x1]. Virtual DSP addr reference that generated the interrupt = [0xedfe9e50].

Now, I've read many posts on the MMU erros but I can't manage to properly setup the memory.

The steps that I've followed till now are:

1- in CFG_OMAP3530_SHMEM.c

        increased CODEMEMORYSIZE from 0x8FF80u to 0x8FFFF80u (the linker cried for this increase)

        increased POOLMEMORYSIZE from  0xD0000u to 0x1000000u (needed to exchange 4MB between ARM and DSP)

        decreased RESETCTRLADDR from 0x8E000000u to 0x85FD0000u (to keep DDR+SHARED+POOL memory below 0x90000000)

        set field MAXBUFSIZE of LINKCFG_dataTable_00 from 16384 to -1 (to remove buffer size limits)

2- in dsplink-omap3530-base.tci

        set DDR2.len to match CODEMEMORYSIZE

        set POOLMEM.len to match POOLMEMORYSIZE

        set RESET_VECTOR.base to match RESETCTRLADDR

3- in boot.scr

        modified the line

setenv mmcargs 'setenv bootargs mem=160M@0x80000000 mem=256M@0x90000000 console=${console} root=${mmcroot} rootfstype=${mmcrootfstype}'

        to

setenv mmcargs 'setenv bootargs mem=60M@0x80000000 mem=256M@0x90000000 console=${console} root=${mmcroot} rootfstype=${mmcrootfstype}'

        in order to avoid overlapping with the GPP OS

Any suggestion is highly appreciated,

Filippo

  • 0
    TI__Genius 12865 points

    Hi Filippo,

    There is a wiki page that talks about this error message: http://processors.wiki.ti.com/index.php/DSP_MMU_Faults. In essence it is saying that your code on the DSP is accessing memory that is not mapped by the MMU and hence it is not accessible. So either there is a mismatch between the memory used on the DSP (dsplink-omap3530-base.tci) and the memory mapped by the ARM ( CFG_OMAP3530_SHMEM.c), or there is a bug in your code (e.g. a bad pointer) that caused it to access invalid memory. So double-check the changes you have made to ensure there is no typo and if you have jtag setup with the DSP, maybe you can try stepping through your code in CCS to find out which line is doing the invalid memory access.

    Best regards,

    Vincent

  • 0 in reply to Vincent W.
    Intellectual 450 points

    Yes, that is more or less what I'm trying to do. Actually I picked up the last working project and restarted from there to change one thing at a time, recompile and run.

    I'll let you know if I work it out.

    Thanks,

    Filippo

  • 0 in reply to Filippo Cona
    Intellectual 450 points

    Finally I found out what I was doing wrong so I'll report it here in case someone else can benefit from my debugging process.

    The problem was that I was not allocating enough stack for my memory hungry application. I thought that increasing the stacksize in the dsplink-omap3530-base.tci file was enough, but I was wrong.

    Since I was just modifying an existing example I never cared about how the task was created. Actually in the main.c file (dsp side) the task loop is created with the following instruction:

    - tskLoopTask = TSK_create(tskLoop, NULL, 0);

    That NULL takes the place of a pointer TSK_Attrs, which is thus initialized with default fields.

    The default stacksize (I found some reference in the DSP/BIOS API guide) is 1024 which is the actual stack size allocated for my task and is far from enough for my application. I managed to set the stack size to an appropriate value with minimum modifications by replacing the previous instruction with the following ones:

    - memcpy(&ATTRIBUTES, & TSK_ATTRS, sizeof(TSK_ATTRS)); // copy the default attributes structure

    - ATTRIBUTES.stacksize = desiredSize // set the desired size in the appropriate field;

    - tskLoopTask = TSK_create(tskLoop, &ATTRIBUTES, 0); // replace the NULL with the modified configuration structure.

    Probably someone who writes its own application from scratch or doesn't need to run an application that requires much stack won't have such a problem.

    However those that start from any of the existing dsplink samples may overlook the implications of the task creation just like me.

    Hope this helps!

  • 0 in reply to Filippo Cona
    TI__Genius 12865 points

    Thanks Filippo for the sharing your feedback. Yes, stack overflow is a common problem that can flare up when one is not keeping tabs on it. The Kernel Object View in CCS 3 and 4 can provide some visibility into TSK stack usage if you have it set up. There are also other tricks here: http://processors.wiki.ti.com/index.php/DSP_BIOS_Debugging_Tips#Cause:_Stack_overflow


    Glad you got your problem figured out.

    Best regards,

    Vincent