Regarding using custom input data sets with MIDAS 2.0 demo on OMAP3530 SOC

Honey,

Is the total CMEM size that you are allocating less than or equal to 16MB? Is the CMEM start address the default one? 

If the pools add up to more than 16MB, you'll need to change the memory map in the corresponding mud.cfg file for the server as listed on the wiki (copy-pasted below for your reference): 
"Another thing to keep in mind is that CMEM total size defined above is 16MB (0x86300000 to 0x87300000). Please either ensure that when you add all the pool sizes your total CMEM size is under 16MB, or modify the memory map as per guidelines here."

If after verifying the above, the error persists, please reply with the following 4 attachments:
1. Run the executable on OMAP3530 command prompt as "CE_DEBUG=3 ./ultrasound -qws >> logfile.txt." This should generate a logfile.txt file on your OMAP3530 filesystem which will contain the debug trace
2. loadmodules.sh (with your modifications)
3. mud.cfg (with your modifications, if applicable)
4. filesys/etc/fstab from your omap3530 filesystem  

-- Uday

Hi Uday,4744.64x416.zip6724.80x416.zip

Thank you for the response.

Total CMEM size allocated for our custom sector data is less than 16MB. The CMEM start address is the default one.

The error still persists as I told in my previous post.

I am attaching the log file, loadmodules.sh and fstab for the sector data (80x416) and (64x416) as separate zip files. Please find it and suggest a solution.

Thanks,

Honey S

Hi Honey,

Your calculations for CMEM buffer pools look consistent with your dataset parameters. However, looking at the log trace for the 80x416 dataset run, for some reason it's running out of CMEM to allocate the contiguous buffer for color input (4 x 524288). Snippet from trace log is below:

[Buffer] Alloc Buffer of size 133120 at 0x43bb1000 (0x87039000 phys)
[BufTab] Allocating BufTab for 4 buffers
OM - Memory_alloc> Enter(0x80000)
OM - Memory_contigAlloc> Enter(size=524288, align=128, cached=TRUE, heap=FALSE)
OM - Memory_contigAlloc> CMEM_alloc(524288) = 0x0.
OM - Memory_contigAlloc> ERROR: CMEM alloc failed
... Failed to allocate memory.

We will need to dig deeper into this and see what exactly is occupying the CMEM pools. To do this, I will need a few more things from you:

#1. Reboot the OMAP evm and copy-paste into a text file everything you see till you get the command prompt. Attach this logBooting.txt to your reply.

#2. Go to your omap command prompt and copy-paste into another log file what you see in the terminal after running the following command
target$ cat /proc/cmdline >> logbootargs.txt

#3. Attach your modified 'mud.cfg' and 'mud.tcf' files from ultrasound/servers/mud/.

#4. In your source code, before every function call to 'BufTab_create' and 'Memory_contigAlloc' can you please add the two lines as below. Modify the print statement based on which Buftab is being created. For example, for the DPU Buftab, it would be:

system("cat /proc/cmem");
printf("BEFORE DPUBUFTABOUT CREATE \n");
hUsProcess->hDPUBufTabOut = BufTab_create(DISPLAY_PIPE_SIZE+1, (MAX_COLOR_POINTS * MAX_COLOR_SCANLINES * sizeof(uint_least16_t)), &bAttrs);

Please make sure you add this before every single BufTab_create and Memory_contigAlloc function call.  Once you have done this, rebuild the executable from source, and then run it on your target as 

target$ ./ultrasound -qws >> logfileCMEMcheck.txt

Attach this logCMEMcheck.txt file to your reply.

-- Uday

Hi Uday,3010.logBooting.txt4331.logBootargs.txt1663.mud.cfg.txt5710.mud.tcf.txt8308.logfileCMEMcheck.txt

Thank you for your reply. I am attaching the requested files for 80x416 sector data. Please verify it.

Note: mud.cfg and mud.tcf are uploaded as text files as those files are not permitted to be uploaded in original format.

Thanks,
Honey S

Hi Uday,

Hope you see the previous post where I attach all the log files you requested.

Adding some more observations while testing custom Bmode sector IQ data with MIDAS. Please check it and send your valuable suggestions.

1. For  the resolution 80 scanlines x 416 samples (1 frame only). For that, I have changed the required parameter files and also calculated the new

pool sizes as per MIDAS 2.0 wiki and edited loadmodules.sh. But when I run the demo, I got  " DSP MMU Error Fault!  MMU_IRQSTATUS = [0x1]"

But on analysing the console prints in detail, I came across an error print in between. 

----------------------------

UsProcess: CMEM allocation of 1228800 bytes for hSCUBufTabOut8
PROFILE_DEMO: Profile info available on console
PROFILE_DEMO: DDRALGHEAP memory takes 5314776 bytes 
Before BPU Config 
UsProcess_configBpu: App-> Control completed
After BPU Config 
UsProcess_configScuB: Configuration before DSP send: inlines=80, insamples=416, outrows=640, outcols=480 
SCU mode=bmode
Error: UsProcess_configScuB: Returned status from UNIVERSAL_control = 0xffffffff
UsProcess_configDpu: Configuration before DSP send: sz=2078 bytes nscan=64
UsProcess_configDpu: App-> Control completed
Color Configuration before DSP send: inlines=64, insamples=256, outrows=640, outcols=480 
UsProcess_configScuColor:App->Control completed.
Check Input file B is  "./userdata/InputData/SectorEpData_416_80.bin" 
Check Input file C is  "./userdata/InputData/FpData_256_64_8.bin" 
SCU, BPU, DPU active

  ------------------------------

2.  For  the resolution 112 scanlines x 416 samples (1 frame only). For that, I have changed the required parameter files and

also calculated the new pool sizes as per MIDAS 2.0 wiki and edited loadmodules.sh. But when I run the demo,

I got  " DSP MMU Error Fault!  MMU_IRQSTATUS = [0x1]"

In this case also, the same error print appears in the console:-

UsProcess: CMEM allocation of 1228800 bytes for hSCUBufTabOut8
PROFILE_DEMO: Profile info available on console
PROFILE_DEMO: DDRALGHEAP memory takes 5341400 bytes 
Before BPU Config 
UsProcess_configBpu: App-> Control completed
After BPU Config 
UsProcess_configScuB: Configuration before DSP send: inlines=112, insamples=416, outrows=640, outcols=480 
SCU mode=bmode
Error: UsProcess_configScuB: Returned status from UNIVERSAL_control = 0xffffffff
UsProcess_configDpu: Configuration before DSP send: sz=2078 bytes nscan=64
UsProcess_configDpu: App-> Control completed
Color Configuration before DSP send: inlines=64, insamples=256, outrows=640, outcols=480 
UsProcess_configScuColor:App->Control completed.
Check Input file B is  "./userdata/InputData/SectorEpData_416_112.bin" 
Check Input file C is  "./userdata/InputData/FpData_256_64_8.bin" 
SCU, BPU, DPU active

3. But for the IQ data with 64 scanlines and 416 samples, where I don't get any error prints on the console, 

but the application failed. These prints appear to be like the following:-

UsProcess: CMEM allocation of 1228800 bytes for hSCUBufTabOut8
PROFILE_DEMO: Profile info available on console
PROFILE_DEMO: DDRALGHEAP memory takes 5301464 bytes 
Before BPU Config 
UsProcess_configBpu: App-> Control completed
After BPU Config 
UsProcess_configScuB: Configuration before DSP send: inlines=64, insamples=416, outrows=640, outcols=480 
SCU mode=bmode
UsProcess_configScuB: App-> Control completed
UsProcess_configDpu: Configuration before DSP send: sz=2078 bytes nscan=64
UsProcess_configDpu: App-> Control completed
Color Configuration before DSP send: inlines=64, insamples=256, outrows=640, outcols=480 
UsProcess_configScuColor:App->Control completed.
Check Input file B is  "./userdata/InputData/SectorEpData_416_64.bin" 
Check Input file C is  "./userdata/InputData/FpData_256_64_8.bin" 
SCU, BPU, DPU active

Thanks,

Honey S

Regarding post of additional observations, I have found the cause of the issue: "Error: UsProcess_configScuB: Returned status from UNIVERSAL_control = 0xffffffff".

This is due to the wrong implementation of verifying sector input data compliance inside the STK-MED function 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);
}

Note :- The problem of DSP MMU Error fault still persists :(

Hi Uday,

I am now trying to run custom data with MIDAS with various combinations. "DSP MMU Error fault" is occuring many times. In order to avoid confusions by adding all those into same thread, I am putting a new post regarding new experiments and observations.

The problem is becoming too serious now and we have to solve it as soon as possible.

Thanks,

Honey S

For others who might run into this post in the future, the discussion has moved to a new e2e post at http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/160618.aspx

-- Uday