Using MJPEG Decoder on HDVICP2 of the DM816x

Hi Erkka,
Do you see this issue specifically with MJPEG decoder or also tried with other decoders like H.264? This question is to get more infomration on setup.
Also below point is not clear:

I have tried to power up IVAHD0 co-processor via the code provided by the decoder and it seems
to be working at some level because now when using JTAG connection I
don't need to use GEL-script to power up IVAHD0.

when you are saying that you added the IVAHD0 power up code  - where did you add? What do you mean by it seems to be working at some level - can you please elaborate this observation?

Thanks,
With Regards,
Pramod

Hello Pramod,

I have tested the MJPEG decoder and unofficial MJPEG encoder - I have mainly worked with this encoder - but not with any other codecs at the moment.

Basically I have defined build time flags so that when HDVICP_Reset (jpegvdec_rman_config.c) is called the code block that will reset the device is enabled.

I have also tested adding some code from the GEL-files to my own code executed in M3 example:

  GEL_TextOut("\tPRCM for IVHD0 is in Progress, Please wait.....  \n","Output",1,1,1);
  WR_MEM_32(CM_IVAHD0_CLKSTCTRL,         2); /*Enable Power Domain Transition*/
  while(RD_MEM_32(PM_IVAHD0_PWRSTST)!=0x37);    /*Check Power is ON*/
  WR_MEM_32(CM_IVAHD0_IVAHD_CLKCTRL,     2); /*Enable IVHD0 Clocks*/
  WR_MEM_32(CM_IVAHD0_SL2_CLKCTRL,     2); /*Enable IVHD0 SL2 Clocks*/

and so on. But I have removed those additions.

when you are saying that you added the IVAHD0 power up code  - where did you add? What do you mean by it seems to be working at some level - can you please elaborate this observation?

I meant that without the code when using JTAG I earlier needed to use GEL-scripts to power up the co-processor (IVAHD0). Now with the code I don't need to use the GEL scripts for that while using JTAG to load the program. Of course I need to connect to the Cortex-A8 and use script to power up the M3 but I don't need to power up the IVAHD0 like I had to do earlier.

Br,

Erkka

OK - I understood the details of JTAG part. Can you share the details of versions being used (Linux kernel etc)...
Also hard fault is observed on M3 - right? Could you get the details on the place where the hard fault occurs?

Thanks,
With Regards,
Pramod

// More /proc/version on the device.
Linux version 2.6.37 gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)

// From the encoders makefile ie. used to build the encoder test app.
ivahd_hdvicp20api_01_00_00_19_production
framework_components_3_21_02_32
xdctools_3_22_04_46
xdais_7_21_00_02

// From the Syslink samples products.mak ie. used when building the sample.
linux-2.6.37-psp04.00.00.12
ipc_1_23_03_31
bios_6_32_01_38
xdctools_3_22_01_21
C6000CGT7.2.6

// CCS.
Code Composer Studio
Version: 5.1.0.07001
TMS470 Code Generation Tools 4.9.0

Yes, the hw fault was observed from the M3 side.
I tried to debug the place where this happens by adding getchar() to the beginning
of the main() of the encoder test app and then using the Syslink slaveloader to launch
the app in HW. When I connected the JTAG from CCS the hw fault prints were already coming.
Then only way to proceed was to suspend M3 and reload the program and then it worked.

But if I recall correctly sometimes I was able to debug from the beginning of the main and the hw faults started to appear after calling JPEGVENC_create (calls ALG_create) for creating the algorithm handle.

Br,
Erkka

Hello,

Some progress with this. We have now been able to integrate a package created from the JPEG encoder into the Syslink sample.

M3 image is loaded and the encoder algorithm handle is created successfully.

However at the moment when calling the Tiler_DataMove function we receive this:

[CortexM3_RTOS_0] ti.sysbios.family.arm.m3.Hwi: line 801: E_hardFault: FORCED
[CortexM3_RTOS_0] ti.sysbios.family.arm.m3.Hwi: line 878: E_busFault: IMPRECISERR
[CortexM3_RTOS_0] Exception occurred in background thread.
[CortexM3_RTOS_0] Exception occurred in ThreadType_Task.
[CortexM3_RTOS_0] Task handle: 0x96802c08.
[CortexM3_RTOS_0] Task stack base: 0x96802c50.
[CortexM3_RTOS_0] Task stack size: 0x5000.
[CortexM3_RTOS_0] R0 = 0x60000000  R8  = 0xffffffff
[CortexM3_RTOS_0] R1 = 0x60000002  R9  = 0xffffffff
[CortexM3_RTOS_0] R2 = 0x0000615e  R10 = 0xffffffff
[CortexM3_RTOS_0] R3 = 0x00000090  R11 = 0xffffffff
[CortexM3_RTOS_0] R4 = 0x968249a4  R12 = 0x00000010
[CortexM3_RTOS_0] R5 = 0xffffffff  SP(R13) = 0x96807628
[CortexM3_RTOS_0] R6 = 0xffffffff  LR(R14) = 0x96828cd3
[CortexM3_RTOS_0] R7 = 0xffffffff  PC(R15) = 0x9685869c
[CortexM3_RTOS_0] PSR = 0x01000000
[CortexM3_RTOS_0] ICSR = 0x0440f803
[CortexM3_RTOS_0] MMFSR = 0x00
[CortexM3_RTOS_0] BFSR = 0x04
[CortexM3_RTOS_0] UFSR = 0x0000
[CortexM3_RTOS_0] HFSR = 0x40000000
[CortexM3_RTOS_0] DFSR = 0x00000000
[CortexM3_RTOS_0] MMAR = 0xe000ed34
[CortexM3_RTOS_0] BFAR = 0xe000ed38
[CortexM3_RTOS_0] AFSR = 0x00000000
[CortexM3_RTOS_0] Terminating execution...

Any ideas how to proceed?

Thanks and regards,
Erkka

Hi Erkka,

where di you get your motion jpeg decoder? is it provided with the development kit or you have integrated from a third party supplier?

Kindest Regards,

Salim

Hi Erkka,

Can you please more details on Tiler_DataMove usage?

-Are you trying to move the data captured in a RAW memory buffer to a Tiled memory buffer to send to encoder for compression?

-Where is this Tile_Datamove function implemented? Are you using this from any libraries provided by TI?

- Can you provide the sequence of operations in your application for create,control, Tiler_DataMove, process calls?

This will help us in better understanding of your issue.

Regards

Sayanna

Hi Salim,

The decoder is from:
http://software-dl.ti.com/dsps/dsps_public_sw/codecs/HDVICP2/index_FDS.html

Br,
Erkka

Hi Sayanna,

The usage of Tiler_DataMove is currently basically identical to the test application provided with the encoder.

The main difference is that while the test application reads the data from an input file to the
input buffer for the encoder in the function TestApp_ReadInput_420SP_YUVData, our implementation
will memcpy the data from a buffer received with the FrameQ to the input buffer for the encoder.

I don't have the source codes for Tiler_DataMove, it is in an library provided along with the encoder.

The sequence goes:

1. Init parameters for the encoder. These are currently hard coded and not read from the configuration file
as in the original test app in the encoder. Values are exactly same as in the test app.

2. Create the algorithm handle, this step goes ok.

3. Control call for get the version of the encoder.

4. Control call to set the dynamic parameters.

5. Control call to get information for number of input and output buffers.

6. Init input buffers, output buffers, in args etc.

7. Copy data received from the FrameQ to the inputBuf->planeDesc[0].buf

8. Tiler_DataMove

9. Call to the process.


One thing to point out is that when disabling tiler usage via configuration then the process call
causes quite similar output than Tiler_DataMove call.

It seems that all initialization code goes through seemingly ok but when trying to use encoder
it won't work. I was wondering whether this has got something to do with the memory mappings?

Or is the problem in the implementation that the input is not coming from a file?

Thanks and regards,
Erkka

Hi,

Attaching customer's source code. (checked with customer that OK to post, nothing confidential included)

1778.Syslink_with_jpeg_encoder.tar.gz

TAR includes sample folder, which is taken from syslink_2_00_02_80/pacakages/ti/syslink

Also inlcuded is JpegEncLib, from which RTSC package can be built and linked into the Syslink samples project.

best regards,

Aslan

Hi Erkka,

Were you able to build and run the sample JPEG encoder application w/o your changes? In that case we can review the changes in specific.

Regards

Sayanna

Hi Sayanna,

I was able to compile the encoder test application after some modifications to its makefile - otherwise without my changes. After that I was able to run the encoder successfully with JTAG connection. But not without the JTAG connection. It seems that when connected via JTAG the configuration and input files needed by the original test app were opened from PC ie. the application was able to access them. Without JTAG it could not find the needed files - I quess there is no direct access to Linux file system from M3 - and the codec failed.

So to me it seems that running via JTAG results versus without JTAG results can not be compared directly. The library I have created is basically the encoder test app created as RTSC package with the change of receiving the input from a buffer instead of a file + integrated into the syslink sample ie. receiving the data from A8 via FrameQ. I believe this  issue might have got something to do with the memory mappings because integrating the library with syslink sample needed some mapping changes which I was not totally certain of.

I have not tried this combination yet: Syslink sample + Jpeg library changed back to read the data from the input file + JTAG connection so that the library can access the file. This would perhaps rule out the "input data from buffer" issue.

Br,

Erkka

Hi Erkka,

Understood. Thanks for the detailed mail. I think the proposed experiment (with JTAG+syslink+ input from file) will rule out input data issue. Please let us know your observations with this experiment.

Regards

Sayanna

Hi,

I had some time to test this. The result was same even though reading the data from a file.

Br,

Erkka

Hi,

Some progress with this issue. I was able to reconfigure my memory map so that the encoder doesn't hang up anymore or give any hw faults. It currently returns encoding failed but I believe this is a step forward. Now I need to recheck my parameters and perhaps test again with the file loading.

Br,

Erkka

Hi Erkka,

Can you please share the error code returned by the encoder? The error code is populated in "outArgs.viddecOutArgs.extendedError".

Regards

Sayanna

Hi Sayanna,

Thanks for the great tip! The extended error code returned is 32768.
When I mask it to the IJPEGVENC_ExtendedErrorCodes there is no error for bit 15 defined.

But if I mask it to the IjpegVENC_ErrorStatus the bit 15 is declared as JPEG_INVALID_INPUT_BYTES_ERROR.

On the other hand the user guide of the encoder says:
JPEG_INVALID_INPUT_BYTE Bit 15 S_ERROR This error code has been deprecated.

Thanks and regards,
Erkka

Hi Erkka,

The error code 0x8000 (15th bit) corresponds to XDM_FATALERROR.

Can you please get the detailed error codes? It can done using XDM_GETSTATUS control call.Please do following code changes to get the error codes.

1. In algorithm_create()

replace status.videnc2Status.size       = sizeof(IVIDENC2_Status); with status.videnc2Status.size       = sizeof(JPEGVENC_Status);

2. Add the following code after JPEGVENC_encodeFrame call.

    JPEGVENC_control(handle,
                       XDM_GETSTATUS,
                       (JPEGVENC_DynamicParams *)&dynamicParams,
                       (JPEGVENC_Status *)&status);

and collect the following error codes from status

status.extendedErrorCode0

status.extendedErrorCode1

status.extendedErrorCode2

status.extendedErrorCode3

These error codes will give more details of the cause of the error.

Regards

Sayanna

Hi Sayanna,

Thanks for the clarification. Here are the new traces:

DEBUG: VIDEO-M3: status.extendedErrorCode0: 16777216
DEBUG: VIDEO-M3: status.extendedErrorCode1: 0
DEBUG: VIDEO-M3: status.extendedErrorCode2: 0
DEBUG: VIDEO-M3: status.extendedErrorCode3: 0

This was tested with the yuv-data read from a file.

Br,
Erkka

Hi Erkka,

The error code0 = 0x1000000 (24th bit set) means outArgs.videnc2OutArgs.size is not proper.

It should be = sizeof(IVIDENC2_OutArgs) or  =sizeof(JPEGVENC_OutArgs).

Can you please check the value of  outArgs.videnc2OutArgs.size before JPEGVENC_encodeFrame() call and confirm whether it is as expected above?

Regards

Sayanna

Hi Sayanna,

Yes, the size was wrong for some reason even though it was set earlier:

DEBUG: VIDEO-M3: Sizeof outArgs.videnc2OutArgs.size: 352
DEBUG: VIDEO-M3: Size was correct! No need to reset.
......
DEBUG: VIDEO-M3: Sizeof outArgs.videnc2OutArgs.size: 1845505552
DEBUG: VIDEO-M3: Size was wrong: it should be 352


This is weird because it was set in the algorithm_create and after that
it should not change. It is not even given to any function that could do
that. In fact JPEGVENC_encodeFrame is the next time it is used.

So doesn't this mean that something overwrites its memory area?

I have added more traces and after setting the size the application
freezes to this:

DEBUG: VIDEO-M3: Calling JPEGVENC_encodeFrame()
DEBUG: VIDEO-M3: MEMUTILS_getPhysicalAddr
DEBUG: VIDEO-M3: MEMUTILS_getPhysicalAddr
DEBUG: VIDEO-M3: MEMUTILS_getPhysicalAddr
DEBUG: VIDEO-M3: MEMUTILS_getPhysicalAddr
DEBUG: VIDEO-M3: MEMUTILS_getPhysicalAddr
DEBUG: VIDEO-M3: MEMUTILS_getPhysicalAddr
DEBUG: VIDEO-M3: MEMUTILS_getPhysicalAddr
DEBUG: VIDEO-M3: MEMUTILS_getPhysicalAddr
DEBUG: VIDEO-M3: MEMUTILS_getPhysicalAddr
DEBUG: VIDEO-M3: MEMUTILS_getPhysicalAddr
DEBUG: VIDEO-M3: MEMUTILS_getPhysicalAddr
DEBUG: VIDEO-M3: MEMUTILS_getPhysicalAddr
DEBUG: VIDEO-M3: MEMUTILS_getPhysicalAddr

I don't know whether that is relevant now if the memory gets overwritten...

Thanks and regards,
Erkka

Hi,

It seems that tiler memory area is overlapping with application memory area. When tiler_init is called outArg gets overwritten.

Br,

Erkka

Hi Sayanna,

I could not figure out why the tiler_init causes tilerParams to exceed its space.
However we managed to solve this temporarily by adding a dummy variable in the stack right after the tilerParams.

And I finally got - just a few minutes ago - the encoder working with the Syslink sample!
There were also problems with the ISR vector table when merging the encoder lib with the Syslink sample.

Br,
Erkka