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.

[Custom IQ data with MIDAS 2.0]: DSP MMU Error Fault! MMU_IRQSTATUS = [0x1]. Virtual DSP addr reference that generated the interrupt = [0xfe00fe00]

Other Parts Discussed in Thread: MIDAS

Hi all,

I am trying to run custom IQ data with MIDAS 2.0. For that, I have chosen IQ data combinations which satisfy the multiplicity requirements of MIDAS2.0 (ie scanlines, multiple of 16 and samples, multiple of 32).

What I have done is - I have fixed a maximum target of my scanlines/samples possibility [ie, Bscanlines 512, Bsamples 1024, Dscanlines 256, Dsamples 512 and Densembles 12) and calculated the poolsizes accordingly. Then I have changed my loadmodules.sh to change my CMEM start and end addresses and my pool sizes. Then I have modified my mud.tcf file to change the size of DDRALGHEAP. Then I rebuild the dsp server and the MIDAS application. Then I have changed the bootargs of OMAP3EVM so that linux memory is reduced to 72MB(This is calculated after several trial and errors). Then the application worked fine when I provide an IQ data of same resolutions. (Bdata - 512x1024, color data 256x512x12)

My assumption is that: If I anticipate the maximum possible resolution of custom IQ data and calculated the poolsizes, configured mud.tcf and loadmodules.sh accordingly, I could run any IQ data of lower resolution which also satisfy the multiplicity requirements. But the below are my observations while testing:-

 

1. When I run linear Bmode data with 384 scanlines and 640 samples, I got DSP MMU error fault.

2. When I run linear Bmode data with 112 scanlines,and 1024 samples, also I got DSP MMU error fault.

During both cases, DSP MMU Error Fault!  MMU_IRQSTATUS = [0x1]. Virtual DSP addr reference that generated the interrupt = [0xfe00fe00] error occured.

I understood from many forums that DSP MMU error fault occurs when an address referred is not already mapped in MMU. But I don't know from which portion, the address 0xfe00fe00 is being referred. This seems to be like a junk value.

Is my understanding for running the whole procedure correct? Did I miss anything?

I am pasting all the required files below. Please help me solve this issue. I am now stuck with this issue. We need to solve it as soon as possible. Thanks in advance.

************************************************************************************************************************************************************************************Log redacted******************************

Thanks,

Honey S

 

  • Hi Honey

    Your understanding looks correct and lower scanline or sample sizes, as long as they meet module requirements (multiplicity, max. size), should work if the higher scanline/sample sizes work. 

    One thing I noticed from this log, is that the UNIVERSAL_process call that is failing seems to be related to the DPU call. Also I notice before the MMU error, there is another error:

    "Wallfilter file = ./userdata/LUTs/TI_Carotid_WallFilterCoeff_001.bin
    Error in reading DPU Wall Coeff file ./userdata/LUTs/TI_Carotid_WallFilterCoeff_001.bin"

    It doesn't seem to find the wall filter coefficient file. It could be that the files doesn't exist or have something to do with the permissions on that .bin file. Have a look and ensure that the wall filter coeff file can be ready successfully. Also remember that if you are changing the number of ensembles, you will need to generate a wall filter coefficient corresponding to that. 

    If the above doesn't work, another check you can do quickly to help us get to the root of this, is to modify the loadmodules.sh, mud.tcf, etc. to be exact for the 384x640 use-case. Then also try the same for the 112x1024 use-case and rerun. See if those work. 

  • Hi Uday,

    Thank you for the suggestions. But unfortunately, all of those modifications didn't help.

    I am pasting the log files, loadmodules.sh and mud.tcf for the 380x640 use-case below and 112x1024 use-case in next post. Please analyse it. I need to solve it as soon as possible :(

    1. For 384x640 use-case, generated the wall filter coefficient file, the following is the log:-

    ============ Texas Instruments Inc ==============

    Edited

    Thanks,

    Honey S

     

  • For the 112x1024 use-case, the following are the log files:-

    Log deleted

    Thanks,

    Honey S

  • It looks like the log in the case where you are using the loadmodules.sh, etc. to be exact as the dataset has no errors, so let's first make sure that this works correctly.

    1. How many input frames of custom input data are you providing? 

    2. When you say the output is hanging, do you mean you see only 1 output frame being continuously displayed and no running video? 

    3. If yes, does the output frame look as expected? If no, do you see anything else on the screen in this case or is it always just blank?

    In either case, the way to debug further, is to write the contents of the input frame, output frame after BPU, output frame after DPU and output frame after SCU to different files, so you can analyze these frames to see if they look correct. To do this, you can use something like the 'logBuffer' function below and write the contents to a binary file, and then analyze it in MATLAB. Let me know if these look as expected.

    /******************************************************************************
    * logBuffer
    * Logs the contents of a buffer in a binary file
    ******************************************************************************/
    int logBuffer( unsigned char *pBuffer, int bufferSize, const char * filename, const char * mode)
    {
    FILE *file;

    file = fopen(filename, mode);

    if (file!=NULL) {
    fwrite(pBuffer, 1, bufferSize, file);
    printf("Logging %s \n", filename);
    }
    else {
    printf("Creating BPUIn Frame failed");
    return -1;
    }

    fclose(file);

    return 0;

    }
  • Hi Uday,

    Please see my reply to your queries. The following are tested for Bmode data 384x640 and Color mode data 256x512x12 ensembles.

    1. How many input frames of custom input data are you providing? 

    >> Bmode data - 14 frames, Color data - tested with 10 frames and 5 frames.

    2.  When you say the output is hanging, do you mean you see only 1 output frame being continuously displayed and no running video? 

    >> No frame displayed. The screen just freeze when I press "Start" on MIDAS GUI.

    3. If yes, does the output frame look as expected? If no, do you see anything else on the screen in this case or is it always just blank?

    >> The screen just freeze when I press "Start" on MIDAS GUI showing only MIDAS DEMO Menu.

    4.  In either case, the way to debug further, is to write the contents of the input frame, output frame after BPU, output frame after DPU and output frame after SCU to different files, so you can analyze these frames to see if they look correct. To do this, you can use something like the 'logBuffer' function below and write the contents to a binary file, and then analyze it in MATLAB. Let me know if these look as expected.

    >> When I enabled logging to buffers, I got only 3 buffers - bpuout, dpuout and scubout. bpuout and scubout seems to be okay. But dpuout seems to be incorrect.

    FYI:- I could successfully run Linear Bmode data 384x640 and Color mode data 128x416x12 ensembles data. Also I could successfully run Bmode data 384x736 and color mode data 128x416x12 ensembles. These all worked with modified memory map targeted for Bmode data 512x1024 and color data 256x512x12 ensembles.

    But still issues with Bmode data 384x640, Color data 256x512x12 ensembles and Bmode data 112x1024 and Color mode data 256x512x12 ensembles.

    By the way, I am now starting to test with Sector data. I will update with the observations while running those too.. 

    I need to fix the issues very soon. :(

    Thanks,

    Honey S



  • Hi Uday,

    I have finally resolved the issue "DSP MMU error fault". On further debugging, I found that my issue is isolated to the scu unit. So I decided to rebuild the scu dsp code.

    I didn't do any modification to source code except the one which I mentioned earlier for the sector data where the logic for checking sector compliance is wrong. Then I recompiled "scu" in code composer studio and rebuilt the midas application with the new scu package. 

    Thus now my linear and sector data work with no DSP MMU error fault. I assume some instability in the older scu package. 

    Thanks for your support. 

    Thanks,

    Honey S

  • Hi Honey

    Thanks for the update. Glad your custom datasets are working with MIDAS 2.0 now. Could you please mention the code change you had to make for the 'sector compliance' test in SCU.

  • Hi Uday,

    The following explains the code modification:-

    SCU_TI_checkCompliance_sector() in scuConfig.c.

    The function logic says to be sector compliant, both the scanlines and samples should be multiple of 32. (It was by mistake. The comment written was right, but the condition check code was wrong). The following is the code portion:-

     

    scuConfigError_e SCU_TI_checkCompliance_sector (const scuConfig_t *scuConfig_p, 

                                                    int_least32_t angleStartScanLineInRadians,

                                                    int_least32_t angleEndScanLineInRadians

                                    )

    {

      if( scuConfig_p->interpolation != scu_INTERP_ALG_2x2)

        return( scu_ERR_CONFIG_INVALID_INTERPOLATION );

      if( scuConfig_p->inpGeometry.shapeParams.u.sector.scanDirection != 1)

        return (scu_ERR_CONFIG_INVALID_INP_GEOMETRY );

      // check the sector angle.  The current implementation only support sector angle +-50 degree relative to the Y-axis

      if( (angleEndScanLineInRadians + Q20_90DEGREE_IN_RADIAN  )

         > Q20_50DEGREE_IN_RADIAN )

        return (scu_ERR_CONFIG_INVALID_INP_GEOMETRY );

      if( ( -angleStartScanLineInRadians - Q20_90DEGREE_IN_RADIAN)

              > Q20_50DEGREE_IN_RADIAN ) 

        return (scu_ERR_CONFIG_INVALID_INP_GEOMETRY );

      if( scuConfig_p->inpGeometry.depthEnd + scuConfig_p->inpGeometry.shapeParams.u.sector.radiusOfCurvature > Q20_64cm )  

          return (scu_ERR_CONFIG_INVALID_INP_GEOMETRY );

      // current implementation requires number of samples per scan line is integer multiple of 32

      if( ((scuConfig_p->inpGeometry.numScanLines)&0x1f) != 0 )

        return (scu_ERR_CONFIG_INVALID_INP_GEOMETRY );

      // current implementation requires number of scan lines for B-mode is integer multiple of 16

      if( (scuConfig_p->mode == scu_BMODE) || (scuConfig_p->mode == scu_BMODE_422) )

        if( (scuConfig_p->inpGeometry.numScanLines & 0xf) != 0 )

          return (scu_ERR_CONFIG_INVALID_INP_GEOMETRY );

      return(scu_CONFIG_NOERR);

    }

    In the highlighted portion, number of scanlines variable should be replaced with number of samples variable.

    Thanks,

    Honey S