Issue writing to memory using the DSP on the 6467T EVM

Hi Vincent - thanks for your reply.  Jeff is out today, so I'll follow up on what I can.

Vincent said:

I am not 100% sure I fully understand the problem you are facing. I think you are saying you have allocated a buffer of size > 0xe1000 bytes and not being able to write to byte 0xe1001. Are you saying you cannot access memory in a specific address range?

We are allocating a buffer of size 0x151800 (1280 x 720 x 3 /2), which is sufficient to contain a YUV image of size 1280 x 720 in YUV420P format.

We are now trying to simply use the same code on DM6467T.  Due to CMEMK version dependency, we have used the latest DVSDK 3.10 (_12) to rebuild our codecs, our codec server, and our ARM application code (based on DMAI libraries).

We have written a codec which converts the format from YUV420P to YUV420PSEMI.  This codec works normally and without error on the DM6467 EVM from 2008/2009, using DVSDK 2.00.

On the DM6467T, our existing code does not work the same way.  Any data writes from offset 0 to offset (1280 x 720) -1 work normally.  Thus, the Luma portion of the image is copied as expected.   Any data writes starting at offset 1280 x 720 (0xe1000) fail, and the resulting written data is 0x00, even though we are writing into our allocated buffer space (not beyond).

We can read locations beyond 0xe1000.  We cannot write.  Any attempts to write from 0xe1000 through the end of the buffer result in 0x00 being written, regardless of whether we use memcpy, or an intrinsic 8-byte write.

Have you tried creating the buffer at a different memory location?

We are running in a dynamic environment on an actual device, using the (previously working) codec and codec server config files.  It seems unlikely that we would end up having the exact same memory location allocated to us by CMEMK each and every time.  So, I believe we've effectively tested different memory locations by default.

How are you verifying that data has not been written out correctly? Are you doing this comparison programmatically? Or are you using CCS?

One test that we ran was that we did a single memset action to write 0xFF to the entire allocated buffer - 0x151800 bytes.  We found that the first 0xe1000 bytes were correctly set to 0xFF, and the remaining bytes were set to 0x00.

In other tests we have captured the buffer returned by our codec to a file, and then analyzed the content of the file.  We can capture the output of the TI JPEG decoder to a file, and confirm that the JPEG decoder is correct.  Then, after color conversion using the color conversion codec described above, the color information is corrupted.  Meanwhile, the exact same code runs correctly on the DM6467 EVM.  If we manipulate the exact same buffer using ARM code instead of DSP code, the color information is manipulated correctly.

Also, we can visually see the result of this problem, since an image with all 0x00 values for both Cr and Cb is green at all locations.  Sort of a monochrome black and white image in shades of green.  We're calling this 'green screen'.

We are not using CCS.  We are awaiting version v4.2 of CCS so that we can develop and debug on Linux.  And, we need DM6467T device emulation, I think, to find this issue.

For problems with memory access in general, good things to double-check are buffer placement (buffer needs to be placed in writable memory), alignment (unaligned access will give strange results), and cache (disable the cache so that you don't have to deal with coherency issues while troubleshooting).

We are not allocated the buffer at a hard-coded or fixed address.  We are using the TI tools to create a buffer per the DMAI example code.  Is it possible for CMEMK to allocate buffers in non-writable memory?

We are using memory aligned access.

We will investigate the cache settings on the codecs.

Thanks for your help.  I hope that my response helps clarify our issue.  I'll follow up with the results of the cache investigation.

Eric

Hi Vincent,

As suggested we turned off all caching and this did not change the output. All writes after 0xE1000 in the data still resulted in 0s.

We ran a few more tests hoping to gain a better understanding of the problem with this test standing out:

 We decided to modify only a few bytes of the buffer after 0xE1000, and this provided a strange result. By changing only 4 bytes, all data starting at 0xE1000 became 0s. Not just the 4 bytes, but all data starting at 0xE1000 became 0s.

We also wrote data upto 0xE1000, and all data starting at 0xE1000 did not change.

Is there any settings in the DSP BIOS or codec server including memory map that could result in this behavior?

Thanks,

Jeff

Hi Vincent,

First I would like to reiterate one of Jeff's comments above:

- We found that if we simply write data to a few locations (we tried 4, but 1 might be enough), the entire buffer contents from 0xe1000 to the end (460800 bytes) are reset to 0x00.  So, clearly it is not our write that is physically changing the data.  Something else in the device is changing the buffer contents, triggered by our access.  I do not see how this could happen - can you think of a scenario that would cause this?

OK, and in regard to your comments, I want to make sure I clarify our codec.

Our codec should be XDM compliant - it was originally built using the IMG_CPY1 codec in the DVSDK 2.00 examples.  We have not changed the design of the codec - just rebuilt it using the DVSDK 3.10 environment.  So, has something in the XDM implementation changed that would invalidate our old code?

We are using a Codec Engine built by the GenServerWizard from DVSDK 3.10.

According to the SPRAB44 document, which is a 6467 to 6467T migration guide, the memory maps for the 6467 and 6467T are identical.  So far we have tried the following DVEVM memory maps:

1) the default memory map in the DVSDK build

2) the default memory map provided by the GenServerWizard (might be the same as (1))

3) the original memory map that we used with our (same) code on the 6467 using the DVSDK 2.00 tools.

So, if the memory map for the device is unchanged, we are unsure why (3) did not work.  It worked properly on the 6467.

Is it possible that the migration guide is in error, and there is some change needed fro the memory map?

Thanks again for all your assistance - your ideas and comments have been helpful!

Eric

Hi Vincent,

The "green screen" issue has been resolved, but there is still an issue with the CCV. There was a bug in our code that caused all of the data below 0xE1000 to become 0s. That has been fixed and all data is correct. Although the data was correct we were still getting a "green screen." With further testing we discovered that the CCV call is not putting the data in the correct spot in the displays memory. With both the 6467 and 6467T setups the display buffer is a 1080P buffer (1920*1080*2 bytes in size), no matter what the actual image size may be. Thus the luma starts at an offset of 0 and the chroma starts at an offset of 1920*1080. The CCV was placing the chroma at an offset of 1280*720 which was not being displayed.

Is there a way to get the CCV call to place the data in the correct parts of the display buffer?

Thanks for the help,

Jeff 

Hi Jeff,

The VDCE puts the CbCr at ptr + size * 2 / 3 for YUV420SP and ptr + size / 2 for YUV422SP. ptr and size are set by:

    vdce_address_start_t params;
    params.buffers[VDCE_BUF_OUT].index    = -1;
    params.buffers[VDCE_BUF_OUT].buf_type = VDCE_BUF_OUT;
    params.buffers[VDCE_BUF_OUT].virt_ptr = ptr;
    params.buffers[VDCE_BUF_OUT].size     = size;

The VDCE user guide which comes with the PSP release explains this further.

Regards, Niclas

Hi,

Vincent

Could you help me to solve the problem of How to use intrinsics on DM8168?

list here

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/270544.aspx

Regards,

Yang